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 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? NeilBrown PS the reason to want to mount a sub directory instead of just mounting the top level directory is that "/foo/bar" is rather large - over 1000 home directories. Whenever anything does an "ls -l" or similar in there (and it seems that some things do) it causes fairly horrible performance somewhere (lots of uid to name to uid mappings probably being part of it). Using an automounter to just mount the bit that is required seems to help.
Attachment:
signature.asc
Description: PGP signature
