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. 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? -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
