[Fedora-directory-users] posixgroup name lookups

[George Holbert]

John A. Sullivan III wrote:
>> John A. Sullivan III wrote:
>>     
>>> Hello, all.  We're trying to move all our user access control to DS
>>> including file system rights management and thus group management.
>>> We've hit a few problems and would like to share how we've gotten around
>>> them both for documentation and so someone with more experience can tell
>>> us if we are going about this the wrong way.
>>>
>>> The first problem we hit was the various hosts could not resolve the
>>> gidnumber to a name:
>>> -sh-3.2$ id -gn
>>> id: cannot find name for group ID 2000
>>> 2000
>>>
>>> We noticed in the access query that the hosts were looking for
>>> posixgroups:
>>> SRCH base="dc=ssiservices,dc=biz" scope=2
>>> filter="(&(objectClass=posixGroup)(gidNumber=2000))" attrs="cn
>>> userPassword memberUid uniqueMember gidNumber"
>>>
>>> The problem comes with user's initial groups which are typically named
>>> after the uid.  Since we had not created these explicitly as DS groups
>>> but rather simply assigned the gidnumber in the posixaccount's gidnumber
>>> attribute, there was no posixgroup to seek.
>>>
>>> I suppose the ideal way to address this is the change the query to look
>>> for a posixgroup or a posixaccount.  I do not see how one does this.
>>> Instead, we added posixgroup as an objectclass to the users.  Is this a
>>> reasonable way to go about this?
>>>
>>> Then we hit our next problem.  The user's initial group is usually the
>>> same as their uid, e.g., user bsmith belongs to group bsmith. However,
>>> the query is looking for cn rather than uid.  I suppose this is because
>>> a posixgroup, as opposed to a user, does not have a uid but does have a
>>> cn.  This turned up as a problem where we wanted to control the umask in
>>> bashrc which uses logic such as:
>>> if [ $UID -gt 99 ] && [ "`id -gn`" = "`id -un`" ]; then
>>>         umask 002
>>> id -un would return bsmith but id -gn would return something like Brian
>>> Smith.
>>>
>>> Thus, we will need to make it a user creation procedure to override the
>>> cn to be the same as the uid rather than FirstName LastName.  Is this
>>> the correct approach? Thanks - John
>>>   
>>>       
> On Wed, 2008-11-19 at 11:17 -0800, George Holbert wrote:
>   
>>> -sh-3.2$ id -gn
>>> id: cannot find name for group ID 2000
>>> 2000
>>>       
>> ...
>>     
>>> Instead, we added posixgroup as an objectclass to the users.  Is this a
>>> reasonable way to go about this?
>>>       
>> Not really...
>> id is asking your name service "what is the group name for gid 2000".
>> You have no groups defined in your name service with that gid.
>> The most common way to address this is to add a posixGroup object in 
>> your LDAP directory with gid 2000, and whatever name (cn) you like.
>> I would suggest doing this for each account's primary gid.
>>     
> <snip>
>
> Thanks for the reply. Perhaps this is a better approach but I have some
> reservations (which may be more my ignorance than a real problem).  If I
> do this, I have the separate step of maintaining posixgroups for each
> user in a separate entity.  Not only must I create two instead of one
> (times however many thousands of users I have) but I must keep them in
> sync (user delete, user rename).
>
> By adding a posixgroup objectclass to my users, I solve those problems
> and still give my name service a way to resolve the group name.  It
> seems much simpler to manage but I'm just not sure if this does
> something "bad".  Am I missing something? Thanks - John
>   

Most (if not all) LDAP client software that accesses posix attributes 
will not expect this arrangement.
Most sysadmins or developers that might work with your directory 
probably would also not expect this.
Those are the biggest drawbacks that come immediately to mind.
But depending on your usage, might never be a serious problem.

This is a good time to ask yourself:
Do you really need a corresponding groupname / gid for every username / 
uid in your name service?

The answer might certainly be "yes".
But since you're spending time to accommodate this, could be helpful to 
be sure you have reasons beyond rote tradition.