From: Casey Schaufler <[email protected]>
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: [email protected]
Reported-by: Jose Bollo <[email protected]>
Signed-off-by: Casey Schaufler <[email protected]>
Signed-off-by: David Howells <[email protected]>
Tested-by: Casey Schaufler <[email protected]>
---
security/smack/smack_lsm.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
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),
{}
};
Should this go via Al's tree, James's tree, Casey's tree or directly to Linus?
David
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.
--
James Morris
<[email protected]>
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.
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?
On Fri, Jun 14, 2019 at 1:08 PM Casey Schaufler <[email protected]> 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
On Fri, Jun 14, 2019 at 02:24:09PM -1000, Linus Torvalds wrote:
> On Fri, Jun 14, 2019 at 1:08 PM Casey Schaufler <[email protected]> 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...