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. -- 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
