Re: posixgroup name lookups

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users

[Index of Archives]     [Fedora Directory Users]     [Fedora Directory Devel]     [Fedora Announce]     [Fedora Legacy Announce]     [Kernel]     [Fedora Legacy]     [Share Photos]     [Fedora Desktop]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Big List of Linux Books]     [Gimp]     [Yosemite News]

  Powered by Linux