Re: [PATCH 0/3] Various gssd fixes including machine-credential issue.

[Chuck Lever <chuck.lever@oracle.com>]

On Jun 12, 2013, at 2:12 AM, NeilBrown <neilb@suse.de> wrote:

> On Thu, 6 Jun 2013 09:43:36 +1000 NeilBrown <neilb@suse.de> 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