On Wed, 3 Oct 2012 12:27:28 -0400 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > On Wed, Oct 03, 2012 at 03:48:43PM +0000, Myklebust, Trond wrote: > > On Wed, 2012-10-03 at 11:13 -0400, J. Bruce Fields wrote: > > > On Wed, Oct 03, 2012 at 01:46:29PM +1000, NeilBrown wrote: > > > > On Tue, 2 Oct 2012 10:33:34 -0400 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> > > > > wrote: > > > > > > > > > I guess you're right. So it starts to sound more like: "you have a > > > > > confusing setup. Your export configuration says one thing, and your > > > > > filesystem permissions say another. Under NFSv3 the confusion didn't > > > > > matter, but now it does--time to fix it." > > > > > > > > > > > > > That's the best I could come to - I'm glad to have it confirmed. Thanks! > > > > > > > > It is unfortunate that Linux NFS uses an anon credential to mount when krb5 > > > > is in use, and uses 'root' when auth_sys is used (which might be anon if > > > > "root_squash" is active, but might not). > > > > I wonder if it would work to use auth_none for the mount-time lookup, just > > > > for consistency.. > > > > > > > > Is the following appropriate? Is there somewhere better to put this caveat? > > > > > > Unfortunately, it's more complicated than this, as it depends on client > > > implementation and configuration details. > > > > > > Something like this would be more accurate but possibly too long: > > > > > > Note that under NFSv2 and NFSv3, the mount path is traversed by > > > mountd acting as root, but under NFSv4 the mount path is looked > > > up using the client's credentials. This means that, for > > > example, if a client mounts using a krb5 credential that the > > > server maps to an "anonmyous" user, then the mount will only > > > succeed if that directory and all its parents allow eXecute > > > permissions. > > > > So you're listing this as a "feature" rather than a bug? There should be > > no reason to constrain the pseudofs to use the permission checks from > > the underlying filesystem. > > I'd be fine with that. > > (That still leaves some subtle v3/v4 difference in the case of mount > paths underneath an export? > > What *is* the existing mountd behavior there, exactly? I'm inclined to > think allowing mounts of arbitrary subdirectories is a bug, but maybe > there's some historical reason for it or maybe someone already depends > on it.) > > --b. The behaviour is simple that you mount a filehandle (typically belonging to a directory) and that filehandle can be anything inside any exported filesystem. Yes, please do depend on being able to mount filehandles that aren't to root of a filesystem. The case the brought this issue to my attention involved the server having a directory containing hundreds of home directories. This directory is exported. If they mount that top level directory they get horrible performance. If they use an automounter to just mount the homes that are accessed it works better. They weren't able to explain why but my guess is that some tools (GUI filesystem browser) would occasionally do the equivalent of "ls -l" of the top level directory which would hammer nfs-idmapd and probably ldap.... though you would think that would get cached and not be a problem for long. So maybe it is more subtle than that. I've built similar setups before. There is something attractive about everyone's home directory being /home/$USERNAME even though they are on different servers and different filesystems. In the particular problem scenario, local policy requires that the 'staff' directory on the server to not be world-accessible, but they still want to mount the individual home directories from there onto client machines as required. I cannot easily justify that policy, but the point is that it works with NFSv3 and with AUTH_SYS/no_root_squash, but not with NFSv4/kerb5. I don't think we can fix this inconsistency but maybe we can explain it. I think your text is more accurate than mine, but also a little more vague so the important may not be immediately obvious. That might be a price we have to pay for accuracy. Thanks, NeilBrown
Attachment:
signature.asc
Description: PGP signature
