[Fedora-directory-users] posixgroup name lookups

[John A. Sullivan III]

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
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan at opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society