Re: aname_to_locaname vs gssapi svc/host.domain.org@REALM

On 10/11/2011 11:57 PM, Nico Williams wrote:
> On Tue, Oct 11, 2011 at 11:11 PM, Harry Coin<[email protected]>  wrote:
>> On 10/11/2011 10:46 PM, Nico Williams wrote:
>>> I don't really know what options the Linux NFS server for
>>> root-equivalent access.  So far all I can find are the root_squash and
>>> no_root_squash options.  If you find any other options -- anything
>>> like the Solaris root=<list>    option, let us know.
>> In this example Linux is the client, Freebsd/ZFS the server.   Again to be
>> clear all is well until the principal name has more than one part and the
>> second is not 'root'.    A user with nonzero uid and non zero gid, such as
>> drop root nslcd on linux, when creating a file on the freebsd nfs v4 or v3
>> share, only when kerberos security is enabled, gets mapped to 'nobody:root'.
>>        Not 'nobody:nogroup', 'nobody:root'.
> Yeah, that's bad.  But what's doing the mapping to GID 0?  That's what
> we should be looking for.
>
>> So it's not specific to root, its about the form of the principal name.
> I'm not convinced yet.
>
>>   Ldapwhoami works, local files all correct, nslcd all work.  It's about
>> kerberos somehow.   I thought for sure reverting to nfs3 where the uid:gid
>> is on the wire and not the names the behaviour would change.  Now, the most
>> likley common element is gssd.. and the really unexpected code provided  by
>> heimdal which actually does get referred to by nfs.
> You'll have to trace it more, and post more information.  (What is the
> actual client principal?)
>
> Also, quite clearly this particular instance of this problem would not
> happen if you weren't running diskless, but that it can happen at all
> is disturbing.
>
>>> I'll repeat one more time though that there is *no* GSS-API name-type
>>> of the form<user>@<fqdn>    or<user>/<fqdn>.  The Solaris requirement
>>> that root-equiv clients must have root/<fqdn>@<REALM>    is something
>>> that goes back to 1999 and was really a mistake.  There is no
>>> connection between that name form and GSS, really.
>> What do you make of rfc1964 sec 2.1.2  "Host-Based Service Name Form"where
>> the form of names regarding 'services associated with host computers' is set
>> forth?
> root/fqdn is NOT a host-based service.  You can see this by checking
> the OpenSolaris sources.  You'll see that the host-based name service
> is *not* used when importing the root/fqdn hostname.  This has
> consequences such as: a) no name canonicalization takes place (this is
> a good consequence), b) the default realm gets used, so domain_realm
> doesn't apply, which is a mostly good consequence, at least in so far
> as it means that trusted realms can't claim to be any client to the
> server (the server does byte-wise comparisons in the kernel).  Or at
> least that's my analysis.  You can find the relevant sources here:
>
> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/rpc/sec/sec_svc.c#sec_svc_inrootlist
>
> and
>
> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/fs.d/nfs/lib/nfs_sec.c#nfs_get_root_principal
> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/fs.d/nfs/lib/nfs_sec.c#1023
> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/rpcsec_gss/rpcsec_gss_utils.c#144
> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/rpcsec_gss/rpcsec_gss_utils.c#187
>
> and chasing the references.  Note that in rpcsec_gss_utils.c:187 the
> name-type used is *not* the host-based service name-type, but the
> GSS_C_NT_USERNAME.  If you chase the krb5 mech's gss_import_name()
> you'll see that this just does a krb5_parse_name().
>
> I think that's proof enough that the root/fqdns aren't and weren't
> mean to be treated as host-based service names.  They're just... oddly
> similar :)
>
> That design might not seem ideal, but it's not horrible either, and
> it's not the source of your problem.  Let's find that instead :)
>
>>> I suspect that someone must have thought that having root/fqdn@REALM
>>> for root-equivalent access + the root= option on shares meant that
>>> realm admins could know for sure what clients could possibly get
>>> root-equivalent access.  But the truth is that the server could always
>>> have done whatever it wanted, and any third party vendor's services
>>> could have done whatever they wanted.  The moral is, I think, that
>>> there's not much about an _initiator_ name that could convey
>>> authorization, and that any conventions to do so need to either be
>>> local or very carefully standardized (root/fqdn was never
>>> standardized).  On the acceptor side the acceptor name can convey very
>>> limited authorization information, with domain-based naming being the
>>> most interesting name-type in this respect.
>> Probably took that hint from the RFC. I can't believe how hard it's been
> Maybe, yeah.
>
>> getting a kerberized nfs server going talking cross nfs platform.  Every
> I believe it.  Solaris' client and server, I would hope, are still the
> easiest to deal with, at least with regards to this, though, of course
> there's other issues (like the Solaris server insisting on having the
> ROOTFH be the same as the actual /, which is not ideal).  Of course,
> you're not using a Solaris client for your diskless setup, since that
> has not been supported for years for anything other than netinstall
> (though, FYI, I don't speak for Oracle) -- or at least you're not
> using it in a supported way.
>
>> step a battle and still not there.  First drop root nslcd 'taint ignores
>> environment' so hacking the keytab files, then kstart keytab ownership, now
>> strangeness getting file ownership correct on servers when there's a / in
>> the client's principal name.
> Nico
> --
>
Nico, thanks.    For what it's worth the test setup is not diskless.  
Just a out-of-the-box stable freebsd server (openldap) and a 
out-of-the-box stable debian linux.  Two part principal on client + nfs 
+ kerberos = nobody:root on server.    I'm used to starting with stable 
platforms then growing in useful directions.   Never did I dream what I 
the docs suggested would be so basic turns out to require so much 
end-user patching to get even basic operations going.