[Fedora-directory-users] posixgroup name lookups

[George Holbert]

John A. Sullivan III wrote:
> On Wed, 2008-11-19 at 12:21 -0800, George Holbert wrote:
>   
>> 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.
>>
>>     
> <snip>
> Thanks for the very thoughtful answer.  I'm not only new to LDAP but
> also to Linux based file servers.  I've been in a management role for
> the last decade and before then was doing NDS and NetWare for
> directory/file.
>
> We were planning to use a umask of 007 for standard users and set the
> sgid bit for shared folders.  That's where we thought it would be
> helpful to have a group associated with each user.  In fact, it finally
> made the default setup of creating a group for each user make sense as I
> always wondered why that was done.  I suppose we'll also need to
> activate file system acls for more complex setups as when multiple
> groups need varying access to a shared file system directory.
>
> If that's a silly approach, kindly let me know and point me to some good
> documentation on the subject.  Thanks - John
>   

Sounds like you do have some good (non-silly) reasons.
Just be aware the hybrid posixGroup / posixAccount thing is a unique 
approach, that might well set you up for uniqueness you won't want down 
the road.