On Tue, 2020-01-14 at 13:01 +0800, Ian Kent wrote:
On Tue, 2020-01-14 at 04:39 +0000, Al Viro wrote:
On Tue, Jan 14, 2020 at 08:25:19AM +0800, Ian Kent wrote:
This isn't right.
There's actually nothing stopping a user from using a direct map entry that's a multi-mount without an actual mount at its root. So there could be directories created under these, it's just not usually done.
I'm pretty sure I don't check and disallow this.
IDGI... How the hell will that work in v5? Who will set _any_ traps outside the one in root in that scenario? autofs_lookup() won't (there it's conditional upon indirect mount). Neither will autofs_dir_mkdir() (conditional upon version being less than 5). Who will, then?
Confused...
It's easy to miss.
For autofs type direct and offset mounts the flags are set at fill super time.
They have to be set then because they are direct mounts and offset mounts behave the same as direct mounts so they need to be set then too. So, like direct mounts, offset mounts are each distinct autofs (trigger) mounts.
I could check for this construct and refuse it if that's really needed. I'm pretty sure this map construct isn't much used by people using direct mounts.
Ok, once again I'm not exactly accurate is some of what I said.
It turns out that the autofs connectathon tests, one of the tests that I use, does test direct mounts with offsets both with and without a real mount at the base of the mount.
Based on that, I have to say this map construct is meant to be supported with Sun format maps of autofs (even though I think it's probably not used much).
So not allowing it is probably the wrong thing to do.
OTOH initial testing with the #work.namei branch shows these are functioning as required.
Ian