Re: Mapping user/group ID's in ACLs

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: marius aamodt eriksen (marius@umich.edu)
Date: 05/16/02-11:37:27 AM Z


Date: Thu, 16 May 2002 12:37:27 -0400
From: marius aamodt eriksen <marius@umich.edu>
Subject: Re: Mapping user/group ID's in ACLs
Message-ID: <20020516163727.GA28544@umich.edu>

* William A.(Andy) Adamson <andros@umich.edu> [020516 11:21]:

> > I have two observations.  One is that I don't think Andy's proposed mapping
> > of multiple names to a single uid is correct.  "auth-unix/rees" and
> > "auth-kerberos/rees@umich.edu" may be the same person, but they should not
> > be treated as the same principal for access control purposes. 
> 
> that's up to the administrator. for example, the NFSv4 server could only 
> export the file as under kerberos, but local access is allowed. in this case, 
> the mapping i proposed makes sense.

which also raises the issue of users of the nfsv4 server that don't have
a uid on the server machine.  i believe we were discussing generating
uid's on the fly.  one could also have some sort of reserved uid
scheme, i.e. auth-kerberos/bob@umich.edu doesn't have a local uid on
the fileserver, but a file that he owns will have a special nfsv4 uid,
and auth-kerberos/bob@umich.edu can be stored in an extended attribute
known to the nfsv4 server.  though recalling extended attributes from
the local file system is (most likely) slower than reading a 32 bit uid,
i wouldn't think this would cause a performance problem.

marius.

-- 
> marius@umich.edu > http://www.citi.umich.edu/u/marius


New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:44 AM Z CST