Re: [RFC] MNT_LOCKED vs. finish_automount()

["Eric W. Biederman" <ebiederm@xmission.com>]

Al Viro <viro@zeniv.linux.org.uk> writes:

> 	Back in 2011, when ->d_automount() had been introduced,
> we went with "stepping on NFS referral, etc., has the submount
> inherit the flags of parent one" (with the obvious exceptions
> for internal-only flags).  Back then MNT_LOCKED didn't exist.
>
> 	Two years later, when MNT_LOCKED had been added, an explicit
> "don't set MNT_LOCKED on expirable mounts when propagating across
> the userns boundary; their underlying mountpoints can be exposed
> whenever the original expires anyway".  Same went for root of
> subtree attached by explicit mount --[r]bind - the mountpoint
> had been exposed before the call, after all and for roots of
> any propagation copies created by such (same reason).  Normal mount
> (created by do_new_mount()) could never get MNT_LOCKED to start with.
>
> 	However, mounts created by finish_automount() bloody well
> could - if the parent mount had MNT_LOCKED on it, submounts would
> inherited it.  Even if they had been expirable.  Moreover, all their
> propagation copies would have MNT_LOCKED stripped out.
>
> 	IMO this inconsistency is a bug; MNT_LOCKED should not
> be inherited in finish_automount().
>
> 	Eric, is there something subtle I'm missing here?

I don't think you are missing anything.  This looks like a pretty clear
cut case of simply not realizing finish_automount was special in a way
that could result in MNT_LOCKED getting set.

I skimmed through the code just a minute ago and my reading of it
matches your reading of it above.

The intended semantics of MNT_LOCKED are to not let an unprivileged user
see under mounts they would never be able to see under without creating
a mount namespace.

The mount point of an automount is pretty clearly something that is safe
to see under.  Doubly so if this is a directory that will always be
empty on a pseudo filesystem (aka autofs).

Eric