[556] in Kerberos
Re: [Ted Anderson: principal name standards] and more
daemon@TELECOM.MIT.EDU (Jennifer Steiner)
Fri Dec 16 09:07:52 1988
To: kfall@OKEEFFE.BERKELEY.EDU (Kevin Fall)
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Your message of Thu, 15 Dec 88 14:08:19 -0800.
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
> > Another argument for:
> >
> > 2) it allows users to "delegate" or "partition" their priveleges by
> > creating alternate names for some different "aspect" of their job.
> > For example, there is another entry in the kerberos database, with a
> > separate password, named "wesommer.root"; that identity, while
> > associated with me as a person, has somewhat greater priveledges.
> >
> > Both of these are valuable uses; however, neither is any more than a
> > naming convention.
> >
>
> I tend to agree this is really a naming convention. I am actually sort
> of curious why the convention at Athena has become
> person.root for a 'more priviledged version' of person.
The Athena convention has always seemed backwards to me - i.e.,
the principal should be "root.wesommer" not "wesommer.root".
If we were to put a semantic meaning on name/instance pairs, it
would make more sense to allow users to create *less* privileged
instances of their names. That is, "steiner" might be allowed to
create a "steiner.guest" instance, with privileges that are a subset of
"steiner"'s. Similarly, if anyone is going to create a steiner-as-root
account with greater privileges that "steiner's", it should be "root"
not "steiner".
Jennifer
P.S. One could imagine having more than one level in the instance
hierarchy, like "steiner.guest.jane", "steiner.guest.joe",
which is another argument for having a single arbitrary string
as name, rather than a name field and (one) instance field.
