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 _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
