lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1497022434.5056.4.camel@redhat.com>
Date:   Fri, 09 Jun 2017 11:33:54 -0400
From:   Jeff Layton <jlayton@...hat.com>
To:     David Howells <dhowells@...hat.com>, viro@...iv.linux.org.uk
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        mszeredi@...hat.com
Subject: Re: [PATCH] VFS: Differentiate mount flags (MS_*) from internal
 superblock flags

On Fri, 2017-06-09 at 16:01 +0100, David Howells wrote:
> Differentiate the MS_* flags passed to mount(2) from the internal flags set
> in the super_block's s_flags.  s_flags are now called SB_*, with the names
> and the values for the moment mirroring the MS_* flags that they're
> equivalent to.
> 
> Note that this shows up some interesting issues:
> 
>  (1) Some MS_* flags get translated to MNT_* flags (such as MS_NODEV ->
>      MNT_NODEV) without passing this on to the filesystem, but some
>      filesystems set such flags anyway.
> 

I guess you mean stuff like affs_fill_super which does:

    sb->s_flags |= MS_NODEV | MS_NOSUID;

It seems like it's doing that too late to be useful.

That probably just reflects the fact that it's not very clear how to use
those flags. Probably the right thing is to go over them one by one and
clean up their usage.

> (2) The ->remount_fs() methods of some filesystems adjust the *flags
>      argument by setting MS_* flags in it, such as MS_NOATIME - but these
>      flags are then scrubbed by do_remount_sb() (only the occupants of
>      MS_RMT_MASK are permitted: MS_RDONLY, MS_SYNCHRONOUS, MS_MANDLOCK,
>      MS_I_VERSION and MS_LAZYTIME)
> 
> I'm not sure what's the best way to solve all these cases.
> 

...not sure on this one either.

This is a big patch, but I like this. It seems like a good conceptual
change to separate the external mount() API flags from the internal
implementation. That allows us to make changes to the internal flag
representation in the future without affecting the external API.

Acked-by: Jeff Layton <jlayton@...hat.com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ