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

On 10/24/2011 5:17 PM, Nico Williams wrote:
> 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?
>
>

Sure.  I want everything that worked great here to continue as before 
(ldap, pam_krb5, nslcd, local software) -- except with -sec=krb5x 
kerberos benefits as advertised.  Specifically

A)  without taboo against uid:uname:principal name combinations if I 
specifically indicate I permit them.

and, as pre-kerberos,

B) if a server should offer  N directories for remote access, but 
restricting each of them specifically to F(N) boxes, where F(N) < all 
the boxen in the realm, there exists at least one directory available to 
processes on  box Y but not Z, and likely too some on Z not available to 
Y.  then:

Files written on the share by account-name:uid QQ on Y  will not be 
available to QQ if on Z.  Such files will appear with the QQ's correct 
uname:uid.  Should QQ write on Z, such files may not be visible if on Y, 
but will appear correctly named on Z.   If a process running as QQ 
exists on the server it will have access to both the files written from 
Y and from Z by user QQ.

C)   Unames map onto uids in a 1 to 1 way.   Unames map onto 
'multi-application-use' kerberos principals in a 1 to 1 way.

Just as they all did before kerberos meets network wire 
integrity/privacy assurance.

Except, now with the advertised kerberos ability to authenticate the 
user, or to provide integrity checks of the traffic, or to encrypt the 
trafffic entirely if asked.

Being that it's all free instead of asking for a refund I wrote some 
patches that get it done.  I'll post the relevant bits for discussion,
They're all in a tarball here

http://www.quietfountain.com/krb5nfspatches.tbz

Harry