Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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
