linux-kernel - Re: [RFC][PATCH 00/14] VFS: Make all filesystems implement ->show

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 07 Jul 2017 16:58:56 +0100
From:   David Howells <dhowells@...hat.com>
To:     ebiederm@...ssion.com (Eric W. Biederman)
Cc:     dhowells@...hat.com, viro@...iv.linux.org.uk,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 00/14] VFS: Make all filesystems implement ->show_options()

Eric W. Biederman <ebiederm@...ssion.com> wrote:

> > This makes it easier to implement a context-based mount where the options
> > are passed individually over a file descriptor.  It also allows duplicate
> > options, options that override each other and ignored options to be
> > resolved rather than storing irrelevant data.
> 
> This makes me a little nervous but is probably fine.  But we do need
> to be careful with remount.  Today the rule is all options that need
> to be preserved need to be passed to remount.  Passing options in one by
> one looks like it may make it easy to get that confused while you are
> developing your patches.

Yeah.  We actually currently get this *wrong* in both ext4 and btrfs - and
probably other disk filesystems too.  During ext4 remount and btrfs remount,
the options are parsed directly into the live xxx_fs_info struct, but if
there's a parse error mid-way, we only partially apply the options and have no
idea where it went wrong and what the current state is.

What I'm looking it is breaking it down into a number of steps:

 (1) Parse the options one at a time into a context struct.

 (2) Once we've got all the options, validate the options we've been given
     with respect to themselves.

 (3) Under lock:

     (a) Check the coherency of the options we've been given with respect to
     	 the superblock (if new mount) or the current live state (if remount).

     (b) Apply the options.  This is not permitted to fail.

This gets more complicated under ext4 as you've got an extra option string
stored on disk that you also have to apply and combine with the options
presented to the mount interface.

> Options should be relative to the mount call.  Which is almost always
> &init_user_ns and in the general case would be sb->s_user_ns.

I generally agree with this - my only doubt is that it might leak external
user/group IDs into a container.  Not sure if that's really worth worrying
about, though.

'user' permitted mounts are handled in userspace by a SUID mount program,
right?

David