Subject: RE: Mapping user/group ID's in ACLs

From: "wurzl, mario" <[email-masked]>
Date: Mon, 20 May 2002 12:12:43 -0400

Unfortunately dealing with different name spaces and UID/GIDs require the
use of external mappers, which generate administrative complexity, delays in
authentication and authorization processing, and mapping systems sometimes
create points of failure. In addition, desynchronization between security
databases and mapping databases may either deny a user from accessing data
he/she should have access, or worse allowing  a user access data which
he/she should not allowed, hence creating a security problem.

One way to solve some of these problems, is to use Kerberos' authorization
data field.

The authorization-data-field, which is contained by the service ticket, is
optional and may carry data specific to the end-service (nfs).
For NFSv4 it could contain the user UID, GIDs, and user DNS name.

Having this information would eliminate the need for any form of mapping.
Administrative complexity would reduced and centralized, reducing data
duplication and ambiguity.

Windows 2000 uses the authorization-data-field, which Microsoft calls PAC,
to send among other information, the user SID and SIDs of groups the user is
a member.

The only drawback of the approach is that the KDC will have to aware of
UID/GIDs, but this might not be a major problem for UNIX based KDCs.

Mario Würzl

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]]
Sent: Sunday, May 19, 2002 11:20
To: Noveck, Dave
Cc: wurzl, mario; [email-masked]; [email-masked]
Subject: Re: Mapping user/group ID's in ACLs

"Noveck, Dave" wrote:
> 
> So if "bob" is a user and "auth-kerberos/bob" is not
> (presumably because a user cannot have a slash in it?),
> then the spec answers all my questions below in a way
> that I'm happy with.
> 
> The problem for me is Mike's statement that storing
> "auth-kerberos/[email-masked]" as the owner is a "valid"
> implementation.  Since Mike wrote the spec sections in
> question I'm paying particular attention to his interpretation.
> So was Mike merely saying that the server is free to
> prepend anything (e.g. Lincoln's Gettysburg Address)
> to the actual OWNER attribute on disk as long as it
> strips it off before returning the value?  And that
> it would give an error on a SETATTR of OWNER specifying
> "Four score ... @umich.edu".

It is probable that most implementations will store integers in
their server's file system. Even clean sheet NAS
servers will probably do so, so as to optimize
the use of AUTH_SYS (will we ever eradicate
AUTH_SYS in our time?). So, since it is recognized that
one method of non [email-masked] storage is a valid implementation,
then one has to recognized that it is valid to store anything. As long
as the implementation maps it to a consistent [email-masked]
on the wire. 
> 
> Or was he saying that storing "auth-kerberos/[email-masked]"
> was valid is some other sense, in which case things seem
> a lot more complicated.

I did note that storing auth-kerberos/[email-masked]
is valid, but it opens a mess of problems as soon as
you let RPCs with non-kerberos security flavors
get access.

Mario's understanding is what I intended.

> -----Original Message-----
> From: wurzl, mario [mailto:[email-masked]]
> Sent: Friday, May 17, 2002 4:20 PM
> To: 'Noveck, Dave'; [email-masked]'; [email-masked]
> Cc: [email-masked]
> Subject: RE: Mapping user/group ID's in ACLs
> 
> >From my understanding of the spec., although the server may use any
internal
> format for Owner and Owner_Group attributes, when exchanging these
> attributes with the client (SETATTR or GETATTR), they should be in the
form
> user@dnsDomain UTF8 encoded.

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 20 May 2002 12:18:24 -0500

Unfortunately, your suggestions are Kerberos specific where NFSv4 has
been specified to support other security mechanisms as well (and
potentially others in the future).

Spencer

-- 
Spencer