[Freeipa-devel] How to implement Magic Private Groups in FreeIPA ?

[Simo Sorce]

For some time we have been thinking of implementing a thing called Magic
Private Groups in FreeIPA.

As some of you may have realized in v1 we don't create user private
groups, instead we set ipausers as the default primary group for all new
users. 

This was done for a few reasons:
- avoid the bloat of having thousands of groups just because you have
thousands of users
- avoid synchronization and name/gid conflict problems both at creation
time and at modification time

Unfortunately some of you complained that these are not reasons enough
to abandon private groups, as it make it more difficult to implement
freeipa in places where people is relying on them. Truth be told nothing
prevents admins from manually creating a private groups when a user is
created, but having to do so explicitly is kind of annoying.

There is also another downside of it, the ipausers group quickly grows
and become a behemoth.


Yet simply adding "real" groups for each user would be quite annoying.

So after some thinking I came up with the idea of creating what I call
Magic Private Groups.
The "magic" is in the fact that they are not actually separate objects
but use a neat property of LDAP and objectclasses: you can add
objectclasses and attributes to existing entries (no surprise I know :).
That means we can add the posixGroup objectclass (which determines and
object is a group) to the user along side the posixAccount one.
The MUSTs for posixGroup are cn and gidNumber which are already present
so with some "magic" we have turned an user object from a being a user
account in being *also* a private group for itself.

So, where is the devil ? You'd ask ..

Well there are 1 issue and 1 potential problem.

The "potential" problem is that some client may not like the fact an
entry is both a user and a group at the same time. Clients that behave
that way could be technically considered buggy as there is nothing that
says a user can't be a group at the same time but we need to check if at
least the most common client (nss_ldap) will have any problem with that.
Anyway thanks to the schema compatibility plugin, "bad" clients can
always be told to look at the schema compat tree for groups (like we do
for Solaris clients already as they do not understand rfc2307bis).

The real issue is the user/group name.

Traditionally users use the "uid" attribute to hold the user name, while
groups use the "cn" attribute. Now on a user account "cn" is used to
hold the fullname so we can't just override it with the group name.

Another problem we have traditionally with user and group names is that
both uid and cn have case insensitive syntax, but _posix_ users and
groups are treated as case sensitive on the system (what an irony,
posixAccount and posixGroup haven't been traditionally been really much
posixy after all ...).

This already causes problems with nss_ldap and is in general an issue
for unix clients.

So killing two birds with one stone we are thinking of introducing a new
attribute called posixName that has a case sensitive syntax and does not
conflict with other uses of uid and cn. We will probably still set uid
on users and cn on groups but they will be kept in sync with posixName
(except for cn on user accounts that holds the full name).

nss_ldap can do attribute mapping, so it shouldn't have problem starting
using posixName instead of cn for groups.

This would solve the problem for MPG as at that point all we need is to
have clients search for posixName.

As a plus we can set the uniquness plugin to enforce posixName to be
unique across the whole tree making it impossible to create "real"
groups that have a name conflict with a magic private group.



We are going to make some experiments during this and the next week to
see if we can implement this and still have happy clients, but we would
like to have opinions if anyone have comments about this approach.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York