Re: [PATCH] private mounts

[Trond Myklebust <trond.myklebust@fys.uio.no>]

to den 28.04.2005 Klokka 15:38 (-0700) skreiv Bryan Henderson:
> >Root squashing is there to enforce the policy that nobody gets to access
> >any files with uid=0,gid=0. IOW it is a policy that is first and
> >foremost meant to make root-owned files untouchable.
> 
> That's the only thing it does well, but you'd have to convince me that 
> that's what it was designed for and that's what everyone expects out of 
> it.  The most salient effect of root squashing -- the one that takes 
> people by surprise -- is that it removes the special rights an NFS server 
> otherwise accords to uid 0.  If protecting files owned by uid=0, gid=0 
> were the original design goal, the protocol could have been designed to do 
> that while still giving uid 0 access to everybody else's files.

That is much harder to do. The nfs server would have to take over the
permissions checking on behalf of whatever it is exporting for all
operations.

> >>a process with CAP_DAC_OVERRIDE can get EACCES.  ... Whine, whine...
> >Tough.
> 
> This is actually off-topic.  We're not talking about whether root 
> squashing is a good compromise.  We started with the statement that the 
> only existing thing like (some private mount proposal) is NFS root 
> squashing and the statement that some people consider that broken.  That 
> elicited a response from you that suggested you were unaware there was 
> anything not to like about root squashing ("Really?") and then some 
> descriptions of the objections.  The fact is that negative perceptions of 
> root squashing exist.  I know you know that.  There are respectable 
> technical people who don't agree with the compromise.  So if one is 
> looking for a broadly acceptable design of private mounts, one might want 
> to find one that doesn't use NFS root squashing as its precedent.

The lack of agreement on root squashing is a reason for it to be a
matter of administrator-defined policy, and why the solution chosen
_should_ allow for that kind of behaviour.

If the user is free to futz around with the namespace, then it makes a
lot of sense for administrators to want to restrict access to this
user-defined namespace to non-suid programs that won't start screwing
round with opening files on arbitrary filesystems using the wrong
credentials and/or capabilities.
Particularly so if the user is capable of mounting remote filesystems.

Trond
-- 
Trond Myklebust <trond.myklebust@fys.uio.no>