Re: choosing principal names

On Wed, Oct 5, 2011 at 2:30 PM, Harry Coin <[email protected]> wrote:
> On 10/5/2011 1:28 PM, Nico Williams wrote:
>> On Wed, Oct 5, 2011 at 1:11 PM, Harry Coin<[email protected]>
>>  wrote:
>>> Hear the sound of the can getting kicked down the road.    It is this
>>> group
>>> that defines the concept 'principal', it is this group that has written
>>> into
>>> its libraries uid sensitive default filenames, it is this group that has
>>> a
>>> toe in the water of every OS pond.
>>
>> Absolutely an incorrect conclusion on your part.  The GSS-API
>> specifically addresses standard naming conventions.
>>
> Thanks for that work in your RFC, helpful to gssapi.   Helpful if kerberos
> has no scope outside gssapi and they are to be thought of as a unit and
> maintained together.

It's not that simple.

Kerberos came first, then the GSS-API.  As long as there remain any
raw Kerberos applications, there will remain some principal names that
don't necessarily fit the mold.

> What's a good idea for a system mount nfs client's principal name?  Root?
>  Host?  The name of the package calling mount running as root?  What if the
> package is itself a net service?    Is root to be understood as a person
> with uid:0 and host meaning 'whatever daemons we haven't gotten around to
> giving their own names'?

On the client side there's no standard conventions at all.  Since the
GSS-API's designers expected us to do name-based authorization, that
was never a problem.

The fact that Solaris requires root/hostname for root-equiv access to
shares (plus listing hostnames in the root= share option) is, IMO, a
bug.  Instead Solaris ought to have a per-share list of client
principals that are root-equiv.  (In my time at Sun I might have filed
a bug about this, but if I did I've forgotten the specifics).

Of course, it's because name-based authorization is so... unsatisfying
that we sought to add name attributes.  And that is partly also why,
for example, RedHat is pursuing some PAC-like ideas.

> What's the suggested principal name format an application developer should
> deploy in a package with a client side and multi-homed server side that
> doesn't use gssapi-- that must coexist nicely with systems that do?

See above.  Nothing about raw Kerberos prevents you from applying the GSS model.

> Note Rune and others admonish having name space collisions = bad.  It would
> do well to offer guidance along the lines aforementioned because not all
> application, daemon and api users read everything about what all their peers
> are planning.

Note that it is quite fair to leave the significance of some aspects
of naming is entirely up to the application, not the GSS-API, nor the
mechanism (Kerberos, in this case).  Each application should document
its principal naming requirements.  It's best, of course, for
applications to simply use off-the-shelf name types (and, e.g., in the
case of host-based naming, to specify what service name(s) to use for
what components of the application).

> Not imposed or enshrined in code, but guidance.

Requirements should be documented.  Application developers require
guidance.  There's not enough of the latter, and, in some cases, the
former (but again, the confusion regarding NFS client principals is
mostly a matter of bugs, IMO).

Nico
--