[28] in Kerberos

home help back first fref pref prev next nref lref last post

More on an ACLS

jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:16:53 1987

From BCN%DEEP-THOUGHT@EDDIE.MIT.EDU  Mon Jul 28 22:46:00 1986
From: Clifford Neuman <BCN%DEEP-THOUGHT@EDDIE.MIT.EDU>
Subject: More on an ACLS
To: kerberos@ATHENA.MIT.EDU

Over dinner, srz, spook, and myself discussed the proposal for the
ACLS.  A few additions to the pervious message emerged.

The ACLS will maintain privileges along with each authorization in
it's database.  Right now, we think 8 bits is enough, but I will
entertain arguments for more.  At the service end, each entry for a
group, or direct user will have a mask which will indicate which of
these bits may be used.  For users authenticated directly, only the
mask will be used.  For those authenticated/authorized through the
ACLS, the logical AND of the mask and the privelege bits will be used.
Interpretation of the bits is up to the individual service, but some
kind of convention will be appropriate.

It is desirable to be able to delegate part of the namespace of groups
to particular individuals.  Thus, if I have a unique service, or
services that I provide, and if for some reason it is appropriate for
me to be able to create new ACLs, I can be granted a prefix, under
which I can create other lists.  An example of this would be the
person responible for creating and assigning RVDs.  For each RVD he
create, he will want to create an ACL with the same name.  This is
distinct from allowing someone modify access to an existing ACL.

To avoid the issue of dividing names into components, or choosing a
separator for different parts of an ACL name, I propose granting such
access based on prefixes.  Thus, when I assign part of the namesapce
to RVD, I can choose "rvd_" as the prefix.  If some other application
want's to use something else as the prefix, this is fine too.  

	~ Cliff
-------


home help back first fref pref prev next nref lref last post