Re: [autofs] [RFC] Towards a Modern Autofs

["H. Peter Anvin" <hpa@zytor.com>]

trond.myklebust@fys.uio.no wrote:
> 
> Finally, because the upcall is done in the user's own context, you avoid
> the whole problem of automounter credentials that are a constant plague
> to all those daemon-based implementations when working in an environment
> where you have strong authentication.
> If anyone wants evidence of how broken the whole daemon thing is, then see
> the workarounds that had to be made in RFC-2623 to disable strong
> authentication for GETATTR etc. on the NFSv2/v3 mount point.
> 

It's not broken as much as what you want to do is outside the scope of
automount.  automount is one particular user of these facilities, and as
you correctly point out, it can't solve the problems for all of them.
The right thing for AFS and NFSv4 is clearly to do something different.

Mount traps by themselves are not sufficient for automount, which is why
I think we will always have a special "autofs" filesystem, for the
simple reason that automount in typical use doesn't either have an a
priori complete list of directories!  Even with ghosting you might find
that you're accessing a new key which has not yet been ghosted, and it
needs to be handled correctly.  Additionally, not all map types can be
enumerated, and some aren't even finite in size (consider /net, program
maps and wildcard map entries.)  Thus, for indirect mountpoints you
still need a filesystem which can trap on non-enumerated entries.

That being said, mount traps in particular, and possibly this "trap
filesystem" are more generic kernel facilities which should be of use to
other things than automount.  AFS/NFSv4 are the obvious examples, quite
possibly other things like intermezzo might be interested, and we don't
want to have to reinvent the wheel every time.

	-hpa