diff mbox series

Smack: Restore the smackfsdef mount option and add missing prefixes

Message ID 155930001303.17253.2447519598157285098.stgit@warthog.procyon.org.uk (mailing list archive)
State New, archived
Headers show
Series Smack: Restore the smackfsdef mount option and add missing prefixes | expand

Commit Message

David Howells May 31, 2019, 10:53 a.m. UTC 
From: Casey Schaufler <casey@schaufler-ca.com>

The 5.1 mount system rework changed the smackfsdef mount option
to smackfsdefault. This fixes the regression by making smackfsdef
treated the same way as smackfsdefault.

Also fix the smack_param_specs[] to have "smack" prefixes on all the names.
This isn't visible to a user unless they either:

 (a) Try to mount a filesystem that's converted to the internal mount API
     and that implements the ->parse_monolithic() context operation - and
     only then if they call security_fs_context_parse_param() rather than
     security_sb_eat_lsm_opts().

     There are no examples of this upstream yet, but nfs will probably want
     to do this for nfs2 or nfs3.

 (b) Use fsconfig() to configure the filesystem - in which case
     security_fs_context_parse_param() will be called.

This issue is that smack_sb_eat_lsm_opts() checks for the "smack" prefix on
the options, but smack_fs_context_parse_param() does not.

Fixes: c3300aaf95fb ("smack: get rid of match_token()")
Fixes: 2febd254adc4 ("smack: Implement filesystem context security hooks")
Cc: stable@vger.kernel.org
Reported-by: Jose Bollo <jose.bollo@iot.bzh>
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Casey Schaufler <casey@schaufler-ca.com>
---

 security/smack/smack_lsm.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

Comments

David Howells May 31, 2019, 10:56 a.m. UTC | #1 
Should this go via Al's tree, James's tree, Casey's tree or directly to Linus?

David
James Morris June 3, 2019, 10:42 p.m. UTC | #2 
On Fri, 31 May 2019, David Howells wrote:

> Should this go via Al's tree, James's tree, Casey's tree or directly to Linus?

If it's specific to one LSM (as this is), via Casey, who can decide to 
forward to Al or Linus.
Casey Schaufler June 3, 2019, 11:07 p.m. UTC | #3 
On 6/3/2019 3:42 PM, James Morris wrote:
> On Fri, 31 May 2019, David Howells wrote:
>
>> Should this go via Al's tree, James's tree, Casey's tree or directly to Linus?
> If it's specific to one LSM (as this is), via Casey, who can decide to 
> forward to Al or Linus.

I would very much appreciate it if Al could send this fix along.
I am not fully set up for sending directly to Linus.
Casey Schaufler June 14, 2019, 11:08 p.m. UTC | #4 
On 6/3/2019 4:07 PM, Casey Schaufler wrote:
> On 6/3/2019 3:42 PM, James Morris wrote:
>> On Fri, 31 May 2019, David Howells wrote:
>>
>>> Should this go via Al's tree, James's tree, Casey's tree or directly to Linus?
>> If it's specific to one LSM (as this is), via Casey, who can decide to 
>> forward to Al or Linus.
> I would very much appreciate it if Al could send this fix along.
> I am not fully set up for sending directly to Linus.

Al, are you going to take this, or should I find another way
to get it in for 5.2?
Linus Torvalds June 15, 2019, 12:24 a.m. UTC | #5 
On Fri, Jun 14, 2019 at 1:08 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> Al, are you going to take this, or should I find another way
> to get it in for 5.2?

I guess I can take it directly.

I was assuming it would come through either Al (which is how I got the
commit it fixes) or Casey (as smack maintainer), so I ignored the
patch.

                 Linus
Al Viro June 18, 2019, 1:59 a.m. UTC | #6 
On Fri, Jun 14, 2019 at 02:24:09PM -1000, Linus Torvalds wrote:
> On Fri, Jun 14, 2019 at 1:08 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >
> > Al, are you going to take this, or should I find another way
> > to get it in for 5.2?
> 
> I guess I can take it directly.
> 
> I was assuming it would come through either Al (which is how I got the
> commit it fixes) or Casey (as smack maintainer), so I ignored the
> patch.

FWIW, (belated) ACK...
diff mbox series

Patch

diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 0de725f88bed..d99450b4f511 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -68,6 +68,7 @@  static struct {
 	int len;
 	int opt;
 } smk_mount_opts[] = {
+	{"smackfsdef", sizeof("smackfsdef") - 1, Opt_fsdefault},
 	A(fsdefault), A(fsfloor), A(fshat), A(fsroot), A(fstransmute)
 };
 #undef A
@@ -682,11 +683,12 @@  static int smack_fs_context_dup(struct fs_context *fc,
 }
 
 static const struct fs_parameter_spec smack_param_specs[] = {
-	fsparam_string("fsdefault",	Opt_fsdefault),
-	fsparam_string("fsfloor",	Opt_fsfloor),
-	fsparam_string("fshat",		Opt_fshat),
-	fsparam_string("fsroot",	Opt_fsroot),
-	fsparam_string("fstransmute",	Opt_fstransmute),
+	fsparam_string("smackfsdef",		Opt_fsdefault),
+	fsparam_string("smackfsdefault",	Opt_fsdefault),
+	fsparam_string("smackfsfloor",		Opt_fsfloor),
+	fsparam_string("smackfshat",		Opt_fshat),
+	fsparam_string("smackfsroot",		Opt_fsroot),
+	fsparam_string("smackfstransmute",	Opt_fstransmute),
 	{}
 };