Re: aname_to_locaname vs gssapi svc/host.domain.org@REALM

On Wed, Oct 26, 2011 at 12:02:56PM -0500, Nico Williams wrote:
>  - for most system daemons there's no reason to ever touch NFS (or
> AFS, ...) outside a diskless client case

Sure.

>  - for Apache you either need to give it credentials that have the
> same access as the union of all of Apache's legitimate client users,
> or you need to have it used credential delegation

Exactly.

> Minimizing the number of legit use cases for host-based user naming is
> important because minimizing the impact on the namespaces you have to
> manage is important.  Namespace explosion is not fun, much less cheap.

Agreed.

> > The number of accounts=principals to maintain can become
> > O(<suchaccounts>x<hosts>) but only in an extreme case. It is always
> > O(<suchaccounts>x<accessclasses>) which probably is much less.
> 
> Yes, but that's bad enough IMO because it won't scale to a large
> enough deployment.
> 
> > So it does not have to be complicated and does not need any
> > extra support from the OSs, NFS or Kerberos.
> 
> It requires a suitable aname2lname facility, which Heimdal lacks.

No extra support is necessary if one uses e.g. underscore as a delimiter
for structuring the account name space (if one _can_ do this, of course,
given one's local policies and existing accounts). That was my point
about such solution actually being feasible for Harry.

[Then Kerberos and the local Unices only see a plain namespace,
while the site administrator assigns xxxxxx - like principals to
host-independent users and xxxxxx_yyyyy - like to put principals
in classes named by yyyyy. This works with the existing "literal
equality" mapping present on all NFSv4 platforms, both those using
aname2lname from Kerberos or not.

This implies a quite rigid privilege structure which is not exactly
easy to keep consistent and avoid "name space explosion", right - but
yet probably more manageable compared to a host-based one.

It might fit Harry's needs - if he would not be willing to plainly
forget the old NFS-based privilege structure and redesign from scratch.
The latter would be my recommendation and you seem to feel the same.]

> Also, you really want to avoid collisions with host-based service
> names.  Methinks we should standardize a host-based user naming
> convention for that reason.

Without slashes in the names there will be no such collisions.

> > That said, a deeper redesign would certainly give Harry an even simpler
> > and more maintainable system than keeping those host-related acls which

> The deeper redesign that is coming is labeled security.  I don't know

I meant a redesign of _his_ setup. He is trying to solve problems which
did not have to exist in the first hand.

> what else could replace it while also avoiding the namespace explosion
> discussed above and earlier.

The namespace explosion happens when one artificially puts extra
dimensions into the picture, by one's design choice.

This is what somebody did while designing Harry's system - by using host
identities where they should not be necessary (were it not NFS!).

Allocating privileges to some artificial "units" which group the actual
"acting entities" in irregular ways (like the hosts which contain daemons
of different kinds -- ignoring "system daemons" here of course) - this
is a highly questionable design which is bound to be hard to manage.

It is the acting entity (the daemon) which is relevant to be let acccess
its (remote) resources, the host just provides a runtime environment.
A daemon can be run on virtually any other host, if the system is set
up properly. Then the system is manageable and also secure.

Note, putting daemons on hosts of proper security levels or with proper
local resources like disk or memory or whatnot is a separate matter and
does not have to interfere at all with the daemons' access rights to
networked resources.

It is when irrelevant things interfere - _then_ you get the explosion of
the combinations. Better make it orthogonal, among others not allocating
remote access rights to "hosts".

(Kerberos is about management of identities, so I feel that the above
is not totally offtopic here.)

Regards,
Rune