On Jun 12, 2013, at 2:12 AM, NeilBrown <neilb@xxxxxxx> wrote: > On Thu, 6 Jun 2013 09:43:36 +1000 NeilBrown <neilb@xxxxxxx> wrote: > >> I've provided a patched kernel to customer. Hopefully will hear back soon. > > Hi Chuck, > the patch appears to work exactly as advertised and completely resolves the > issue - thanks. Thanks to you and your customer for confirming the approach. Unfortunately Trond NAK'd a for-3.10 patch that uses RPC_TASK_ROOTCREDS. I posted a patch Friday that takes a different approach to acquiring the root user's credentials that should behave like the old patch in every way, and be easier to back-port. > Getting back to the idea of making this sort of thing work seamlessly, > another possibility to consider is to use the *real* uid of the process > which performs the mount do authenticate SETCLIENTID - either as the primary > authentication or as a fall-back. > Then the a mountpoint with "users" listed as an option in /etc/fstab can be > mounted by anyone with appropriate credentials and no credential should be > needed for root, and not machine credential should be needed either. Perhaps a more common use case with NFSv4 is secure automounter mounts. In that case, the server can be configured to allow sec=sys access to it's pseudo-fs, then require Kerberos for its real file systems. In operation, the client mounts the server's pseudo-fs without needing any GSS context. When it transitions into a protected file system, the server returns NFS4ERR_WRONGSEC and the client should be able to negotiate up to AUTH_GSS using the user's credential. (Mind you I haven't tried this, I'm simply hand-waving based on reasonable assumptions). The key feature of this use case is that the client is not configured for anything but /net. Mount options like "sec=krb5" or "users" are simply not in the picture. The question is still whether, if the client doesn't have a keytab, lease management should use the user's credential or AUTH_SYS. I maintain that AUTH_SYS is a better choice. The kernel cannot possibly know a priori, without configuration, that this is a single-user client and that it is OK to use a user's Kerberos credential for lease management. I'll stress that the reason we prefer a machine credential (either AUTH_GSS or AUTH_SYS) is because a client must present a consistent principal and flavor to the server for lease management. A server can refuse to recognize a SETCLIENTID (for example, after a sudden client reboot) if there is already a lease on the server for using the presented nfs_client_id4.id string that was established using a different security flavor or principal. Otherwise there would be no point in securing lease management. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- 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
