Re: root/ host/ <uid 0 service like nfs>/ ?!?

On Tue, Oct 4, 2011 at 4:57 PM, Harry Coin <[email protected]> wrote:
> And Linux nfs4 client when doing a mount for uid 0 asks for the nfs/<fqdn>
> principal... but, in an abundance of pragmatism, riffles through the keytab
> looking for, in order: root/<host>@<REALM>, nfs/<host>@<REALM>,
> host/<host>@<REALM>,  root/<whatnot>@REALM, nfs/<whatnot>@<REALM>,
> host/<whatnot>@<REALM>.
>
> Seeming to indicate that 'root/' is to mean not a person (nevermind root is
> the only uid:0 account a person can log into with a shell and all), while
> 'host/' appears in the above example as sort of a sorry deprecated synonym
> for 'root'.

Oh, I forgot to mention something important.  The Solaris *server*
will only allow root-equivalent access to shares when either a) the
client's principal is root/hostname.fqdn *and* hostname.fqdn is on the
root= list, or b) when the client principal maps to a user with UID 0
*and* the anon UID for the share is 0.

> There is clarity as principals when people have their account and their
> account/admin principals.   Hoping to extend that clarity to the root /
> service <-> principal naming best practices.

What does the Linux server expect for root-equivalent access?

The server-side convention is the important thing.  Clients can only
really implement something aimed at a standard server-side convention.
 If there's multiple server-side conventions then we have a problem,
particularly if there's no heuristic way to detect what convention a
given server expects.

> Is there consensus that a common understanding has merit for
> <whatnot>/<fqdn> means?

Well, the convention is <service>/<fqdn>.  The <service> part is
defined by the service.  NFS implementations appear to give
significance to <service> = {"root", "nfs", "host"}; anything else
would be rather odd.

Nico
--