Re: Inconsistency when mounting a directory that 'world' cannot access.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 1 Oct 2012 11:43:10 -0400 "J. Bruce Fields" <bfields@xxxxxxxxxxxx>
wrote:

> On Tue, Sep 18, 2012 at 11:23:29AM +1000, NeilBrown wrote:
> > 
> > Suppose that on an NFS server I have a directory
> >    /foo/bar/baz
> > 
> > which I export, and that /foo/bar does not have world access.  e.g.
> > permissions are '750' and everyone who owns files in there is a member of the
> > group which owns /foo/bar.
> > 
> > Then with NFSv3 I can
> >   mount server:/foo/bar/baz  /somewhere
> > because the lookup of /foo/bar/baz happens as root on the server in mountd.
> > 
> > With NFSv4 using 'sec=sys' I can only do this if I export with
> > "no_root_squash", as the lookup happens on the client as root, and if root
> > were squashed, it wouldn't have access beyond /foo/bar.
> > 
> > But if I use NFSv4 using 'sec=krb5', the lookup happens on the client using a
> > machine credential which gets mapped to 'nobody/nogroup' (or whatever anonuid
> > and anongid are set to for the export).  So I cannot perform the mount at all.
> > 
> > This is - at best - inconsistent and can cause confusion (hey - I was
> > confused for a while there).
> > 
> > Should something be done?  Can anything be done?
> 
> I think nfsd_lookup_dentry() would need a special exception for the
> NFSEXP_V4ROOT case.

I don't think that would help in general.
If I export /foo and want to mount /foo/bar/baz, then for the last lookup at
least, NFSEXP_V4ROOT isn't set anywhere near.

An exception would need to be made for every 'nfs4_lookup_dentry', provided
it found a directory, or nothing (or a symlink...).  Possibly this could only
be done for anonymous credentials (as are used by the nfs4 mount operation).

It would be nice if we could clearly differentiate a mount-time lookup from a
regular lookup, but I don't think the protocol allows for that.

Thanks,
NeilBrown


> 
> Looks like the directory permission check is actually done in
> lookup_one_len(), so we'd need to either call something else or
> temporarily swap credentials?
> 
> --b.
> 
> > 
> > I lean towards thinking that the most restrictive behaviour is most correct
> > (though I have a customer who feels that it is too restrictive).
> > 
> > Should the NFSv4 client always use an anon credential when performing the
> > 'mount'?  Is that even possible for auth_sys?
> > Should rpc.mountd use set_fsuid before doing the path lookup to ensure that
> > everyone has access to the exported directory?
> > 
> > Or is there some way 'mount' lookups for krb5 could be treated as being
> > performed by root?
> > 
> > Any ideas?

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux