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

On Mon, Oct 24, 2011 at 4:50 PM, Harry Coin <[email protected]> wrote:
> On 10/24/2011 4:19 PM, Nico Williams wrote:
>
> > 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.
>
> I must respectfully disagree.   While few that might come prepackaged as
> system utilities meant to deliver services to the masses may not, to say
> that none have any business doing so denies the ongoing use of user-specific
> enterprise wide efforts that do just that.

Sure, Apache comes to mind as a daemon that needs to go all over (per
configuration).  But sldapd?  nscd?  no, they don't need to, not
outside a diskless case.  And Apache is special because of what it's
intended for.

Let's get a few things clear:

 - System daemons have no business being NFS clients outside diskless clients.
 - Daemons like Apache, or services that *you* write, might.
     - Such daemons can access NFS using whatever GSS credentials they
care to: all they have to do is have acquired them (e.g., have
kinit'ed).  I believe this is true of Linux's client as well as
Solaris'.
 - On the server-side you'll need to make authorization decisions.
These can be done using PACs (if you have them in your tickets and
have the ability to use them) and/or principal name->authorization
context mappings.
    - Typical NFS servers let you map arbitrary principals to
arbitrary "user accounts" as a way of mapping client principals to
authorization contexts.  I believe this is true of Linux's as well as
Solaris' servers.
    - Yes, Solaris lets you use aname2lname() for this, but that's not
the only option it gives you.  You can also list principal->username
mappings in a "gsscred" file (man gsscred).

Now, can you clarify what it is you want?

Nico
--