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

[Dmitri Pal]

Simo Sorce wrote:
> 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).
>
>   

So posixName will be a part of the user account object and group object,
right?
Can you please add more details here?


> 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.
>
>   


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/