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

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]


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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]