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

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