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

On Mon, Oct 24, 2011 at 4:00 PM, Jeffrey Hutzelman <[email protected]> wrote:
> On Sat, 2011-10-22 at 17:38 +0200, [email protected] wrote:
>> Note that there is a general and straightforward workaround - letting a
>> daemon use different Kerberos credentials for its own service and for
>> accessing the NFS service. This should be easy to setup (_is_ easy on
>> Linux, did not test on other client platforms).
>
> This is an important point.  Both convention and standards encourage the
> use of principal names of the form service/host.fqdn for host-based
> _services_.  However, the behavior of Sun's NFS notwithstanding, there
> is no similar convention dicating the use of user/host.fqdn to name
> principals belonging to _users_ on a particular host.  That is, while
> LDAP clients expect your LDAP server to have the principal name
> ldap/server.example.com, there is nothing that says that a process
> running as local user 'ldap' on host 'server.example.com' must or even
> should use that principal name when authenticating to other services.

But again, *daemons* have NO business using NFS resources unless the
host is a diskless NFS client.  But as I've explained, NFS is a very
poor protocol for diskless clients.  If you do not use NFS for
disklessness, then that problem goes away.

Use iSCSI for diskless, please.

Alternatively, wait until RPCSEC_GSSv3 is widely implemented before
using NFS for diskless clients.  RPCSEC_GSSv3 allows clients to, for
example, assert parts or all of a client process' authorization
context, which the server can then translate to whatever is
appropriate for the given resources, including EACCES.

> Of course, that doesn't help if for some reason you want everything
> running as 'ldap' on hundreds of machines to all be able to access files
> on the NFS server with the rights of (NFS server) user 'ldap', but don't
> want to give them all the key for the 'ldap' user.

I can't tell what Rune wants.  Perhaps that's because there's too much
text to wade through.  A succinct description would be nice.

>> Services other than NFS and login do not need mapping to host-local names
>> anyway.

Says who?  How do you know?  Maybe they do.  All services that use
ACLs using "host-local" identities are going to need to establish an
authenticated client's authorization context such that those
"host-local" identities are part of that context.  Windows makes it
very easy to build such services.  It's not that hard to do the same
on Unix either.

Nico
--