NSS Enhancement: 'realm' table

[Jerry Haltom <wasabi at larvalstage dot net>]

I've not dealt with the libc community before, so I'm unsure of the
specific parties I will be addressing with this post. I suspect however
everybody will have a stake in it. We shall see.

I'll short circuit to the end to save some trouble: I want to propose a
new table be added to NSS. This table would be named 'realm' and will
attempt to solve some of the problems with GNU/Linux in the larger
distributed enterprise. I suspect most of you are well aware of exactly
what it is I'm proposing. I suspect a good deal of you have already
formed your opinions about such a concept or will by the end of this
sentence. I want to know what those are.

Longer story now. As GNU/Linux moves into large scale deployment in the
enterprise, we are going to start to butt up some problems which other
platforms have already come up with solutions for but in which we are
hampered. The problem I am currently addressing is about wide scale
deployments, with THOUSANDS of users deployed across wide areas.
Multinationals, separated by oceans. Companies which have bought out
other companies and desire integration of user/authentication databases.

Typically, such companies use a combination of two technologies to
address these needs: LDAP and Kerberos. Usually these two technologies
manifest themselves in the form of an integrated directory service, such
as Microsoft's Active Directory, some stuff from Novell and a few other
commercial choices. There is work focused on delivering free
alternatives to these platforms. There is work focused on connecting
free systems to these platforms. Of course there is also NIS.

A small organization may have a single LDAP and Kerberos KDC located on
the same box. A larger organization may have many additional LDAP and
Kerberos KDCs located on boxes sitting on the same network. An
enterprise may have hundreds of such boxes distributed across the globe.
In the first two cases, the boxes tend to be responsible for a single
set of users. In the latter case, typically, users are split up amongst
organizational management boundaries. All US users might be on a US
server, all EU users might be on EU users. Typically, for a large
company, it is more fine grained with different LDAP servers per state,
or even building. Completely based on the needs of the organization.
Microsoft calls this configuration a "forest".

Typically workstations and client boxes located under the management
domain of a set of LDAP and Kerberos hosts talk exclusively to those
hosts. User look-ups happen quickly, as the server is located in the
same building, connected with fast links. Things get more complicated
when user look-ups and authentication happens across boundaries. Client
workstations typically have to query remote off-site LDAP servers, or
special local mirrors of remote users and remote off-site Kerberos
servers to establish a secure connection with a remote host. Typical
applications include simple shared file servers, communication between
corporate email servers, video conferencing and remote corporate web
sites.

Again, multiple LDAP servers located in remote sites containing remote
user bases. The term for one of these management domains is usually
"realm" or "domain". Communication within a realm is quick,
communication outside of a realm is usually slower as it is distributed
over WAN links and perhaps the Internet.

Our current NSS makes this situation quite brittle. We have no STANDARD
way to look at a particular passwd or group record and determine what
realm it exists in. We have no way to query for a user list for a
specific realm. We have no way to even know what realms are available.
Typical solutions address the problems in two non-ideal ways:

1) Implement a NSS service which returns ALL users for ALL realms,
munging the user name to include the realm (name@REALM, REALM\name).
Hard code the realm table into configuration files or proprietary LDAP
client services. Hack software to issue realm queries to proprietary
solutions, bypassing NSS (hack a drop down box into a log-in manager,
querying proprietary solution.)

2) Ignore the problem and do not allow cross-realm services.

Obviously the first solution works. There are no FOSS replacements to
the proprietary solutions, because there is no consensus on how to
implement it. Also, nobody LIKES to circumvent established practices.
The second one just ignores the problem and places GNU/Linux at a
disadvantage.

I believe a proper solution would be establishing the idea of a realm
within NSS as a top level object.

Now, don't get me wrong. I recognize the problems with this. I doubt
anywhere in any of the POSIX documents does it describe realm. There's
going to be considerable resistance to changing anything.

In addition to the realm table itself, a number of new functions for
manipulating it would have to be created. First off, obviously, the
general functions to query the realm table itself. Second we would need
functions designed to query passwd and group with regards to a specific
realm. These functions would be nearly equivalent to our existing
getpwent set of functions, except they would take a reference to a realm
along with the existing set of parameters.

The addition of these would allow programs to query for a list of
available realms efficiently instead of being forced to request all
users, parse passwd entries or use a proprietary solution. Additionally,
it would be easier to know which realms which users belonged to in a
more standard fashion than each application being responsible for
parsing munged names.

None of this solves the problem of using munged names, as existing apps
rely on the user name being unique. I suspect that is unsolvable.

Additionally, none of this modifies the existing passwd or group tables.
It merely adds a new table and some functions to join the new table with
the old. Existing applications which query passwd directly will still
get a complete user listing, perhaps containing hundreds of thousands of
results in large settings. Nothing to be done about this except fix the
applications, introduce caching of passwd, and hope for the best.

I suspect my proposal will be under intense fire. If any of these
suggestions fail to take hold, I'm unsure what my next move will be. We
shall see.

Additionally, I am not asking anybody on the libc-alpha list to do this
work. I want to discuss the pros and cons of the solution. Depending on
the outcome, I may take part in implementing it.