On Wed, Oct 12, 2011 at 03:38:03AM -0500, Nico Williams wrote:
> > Note that for authorization purposes NFSv4 server maps the principal names
> > (which are the authenticated identities) to local account names without
> > any extra modification. Then this string is mapped to the server-local
> > numerical uid and its access rights are applied.
>
> It's... more complicated. Or should be, soon enough (because soon
> enough I expect servers to support the PAC).
This _becomes_ more complicated when the actual system architect decides
to move the knowledge of the application-related authorization data to
the KDC (which using PAC implies). It is ok for monolythically managed
installations but actually it makes it harder to see the semantical
relations between different parts of the setup.
(Unix groups is an example of such a widely misunderstood matter, when
a group-by-virtue is directly/implicitely mapped to group-as-an-acl.
In a more sane setup one has groups-by-virtue like "employees" and
a "may-access-these-files"-resource-specific-group which includes
"employees" and "guests". I assume you see the difference. Not many Unix
sysadmins do.)
The "by-virtue" kind of data is natural to manage centrally as it has
nothing to do with the semantics of computing services.
Its mapping to the access rights is to the contrary service specific
and relying on PAC would possibly lead to the KDC sending out a
lot of information about the account - like the monthly salary of an
employee? Unless explicitely taught KDC can not guess which data is of
value for a particular service. So it _will_ be explicitely taught and this
implies a tightly coordinated management, putting the knowledge about all
services at the KDC. Not necessarily the most efficient or desirable way.
As an example, I would hardly be able to transparently use Coda at the
university had I have to put Coda's groups into, say, AD. The latter
would imply a lot of cooperation from the AD managers. Fortunately all
I need to rely on Kerberos is a service principal. It does not harm
that Coda's groups are in a separate database managed by myself. As a
Coda manager I do not want to mess with the University's KDC or other
databases (e.g. have the university's AD managers to allocate database
space and privileges for me to be able to manage this via LDAP, back
and forth. Phew.)
In my eyes it is more straightforward and efficient to let the
service inquire relevant data when and if necessary.
> > specify any extra mappings, like "root/*" to "root". If there is any
> > code which suggests otherwise it is most probably a mistake - this
> > would have long reaching security implications.
>
> Well, see my descriptions of what Solaris does.
Exactly. It looks like we agree that this was a mistake on their part.
> For principal to user mapping MIT has a very configurable rule
> language for aname2lname, and dormant support for using a DB. And it
> could be extended further. IMO Heimdal needs something like it (and,
> indeed, I have patches for supporting the same aname2lname DB feature
> as MIT).
Well, in my eyes it might be a general mapping facility, useful for
certain authentication/authorization scenarios, even those not involving
Kerberos. Thus I'd rather see it as a separate API/something but if some
means of this kind are (going to be) included with Kerberos, I don't mind.
> http://tools.ietf.org/html/draft-adamson-nfsv4-multi-domain-access-04
Thanks for the link. Not that I believe that NFSv4 is a right approach,
it is just a quite complicated compromise.
(AFS has been around for a long time and now NFSv4 tries to reinvent the
wheel with a lot of pain and complexity, with each improvement coming
a step nearer, to more or less the same functionality :)
Best regards,
Rune
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.