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

[H. Peter Anvin]

trond.myklebust@xxxxxxxxxx wrote:
> 
> My point is that the above problem crops up in almost *all* combinations
> of automounter daemon with remote filesystem and strong authentication.
> In order to correctly mount the remote filesystem, the automounter
> itself needs a minimum set of remote privileges (typically it needs to be
> able to browse the remote filesystem).
> 
> RFC-2623 describes how to add RPCSEC_GSS to NFSv2/v3. The
> workarounds (hacks really) that I refer to above had to be deliberately
> added in order to make Sun's automounter work in this environment.
> The alternative would have been to have a global "machine" credential
> for use by the automounter when browsing /net. Hardly secure...
> 

My point is that it's what you get for having an automounter.

We can't solve Sun's designed-in braindamage, unfortunately.  This is
partially why I'd like people to consider the scope of what automounting
does; there are tons of policy issues not all of which are going to be
appropriate in all contexts.  To some degree, if you have to have an
automounter you have already lost.

Also, your global machine credential is to some degree "all the security
you get."  Any security which isn't enforced by the filesystem driver
doesn't exist in a Unix environment; in particular there is no security
against root.  Stupid tricks like remapping uid 0 are just that; stupid
tricks without any real security value.  You know this, of course.
However, if you think the automounter doesn't have the privilege to
access the remote server but the user does, then that's false security.

Linux at this point has no ability to support actual user-mounted
filesystems.  There are things that could be done to remedy this, but it
would require massive changes to every filesystem driver as well as to
the VFS.  Would it be desirable?  Absolutely.  However, it's partially
the quagmire that got the HURD stuck for a very long time, even though
they had the huge advantage of being able to run their filesystem
drivers in a nonprivileged context.

	-hpa

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/