Fedora directory users - Nov 2008 - posixgroup name lookups

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

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

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




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
>

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

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

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.

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@opensourcedevel.com

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

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.

On Wed, Nov 19, 2008 at 03:32:28PM -0500, 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:
[snip]
> <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.
This arrangement is known (at least by Redhat) as User Private Groups
(UPG):
http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/ref-guide/s1-users-groups-private-groups.html

The primary reason for doing it is that group access to files is managed
via secondary group membership, not primary group membership

If each of your users has their own group, then adding a posixGroup
objectclass to each user makes perfect sense. You may also want to place
an uniqueness constraint on the gidNumber attribute as well:
http://www.centos.org/docs/5/html/CDS/ag/8.0/Administering_DSPPR-Server_Plug_in_Functionality_Reference.html#Server_Plug_in_Functionality_Reference-UID_Uniqueness_Plug_in

WRT to linux, the only gotcha I can think of is that you''ll have to set
the nss_ldap nss_base_group option in /etc/ldap.conf to an entry that''s
the common parent to both your users and groups - otherwise it''ll never
find the UPG''s.
> 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@opensourcedevel.com
> 
> http://www.spiritualoutreach.com
> Making Christianity intelligible to secular society
> 
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
-- 
Jonathan Barber
High Performance Computing Analyst
Tel. +44 (0) 1382 386389

Jonathan Barber wrote:
> On Wed, Nov 19, 2008 at 03:32:28PM -0500, 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:
>>>>>           
>
> [snip]
>
>   
>> <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.
>>     
>
> This arrangement is known (at least by Redhat) as User Private Groups
> (UPG):
>
http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/ref-guide/s1-users-groups-private-groups.html
>
> The primary reason for doing it is that group access to files is managed
> via secondary group membership, not primary group membership
>
> If each of your users has their own group, then adding a posixGroup
> objectclass to each user makes perfect sense. You may also want to place
> an uniqueness constraint on the gidNumber attribute as well:
>
http://www.centos.org/docs/5/html/CDS/ag/8.0/Administering_DSPPR-Server_Plug_in_Functionality_Reference.html#Server_Plug_in_Functionality_Reference-UID_Uniqueness_Plug_in
>
> WRT to linux, the only gotcha I can think of is that you''ll have
to set
> the nss_ldap nss_base_group option in /etc/ldap.conf to an entry
that''s
> the common parent to both your users and groups - otherwise it''ll
never
> find the UPG''s.
>
>   
Another way would be to omit the addition of the posixGroup on your 
account objects, and just modify the filter on nss_base_group to include 
posixAccounts.
e.g.:
nss_base_group  
dc=example,dc=com?sub?(|(objectClass=posixGroup)(objectClass=posixAccount))

posixAccount already includes the gidNumber and cn attributes, which is 
all you''re really after here... unless you want to start adding 
memberUid attributes to your account objects (which doesn''t make any 
obvious sense).

You will almost certainly have to modify your nss_base_group setting in 
either case, as Jonathan suggested.

>> 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@opensourcedevel.com
>>
>> http://www.spiritualoutreach.com
>> Making Christianity intelligible to secular society
>>
>> --
>> Fedora-directory-users mailing list
>> Fedora-directory-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>     
>
>

On Thu, 2008-11-20 at 09:01 -0800, George Holbert wrote:
> Jonathan Barber wrote:
> > On Wed, Nov 19, 2008 at 03:32:28PM -0500, 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:
> >>>>>           
> >
> > [snip]
> >
> >   
> >> <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.
> >>     
> >
> > This arrangement is known (at least by Redhat) as User Private Groups
> > (UPG):
> >
http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/ref-guide/s1-users-groups-private-groups.html
> >
> > The primary reason for doing it is that group access to files is
managed
> > via secondary group membership, not primary group membership
> >
> > If each of your users has their own group, then adding a posixGroup
> > objectclass to each user makes perfect sense. You may also want to
place
> > an uniqueness constraint on the gidNumber attribute as well:
> >
http://www.centos.org/docs/5/html/CDS/ag/8.0/Administering_DSPPR-Server_Plug_in_Functionality_Reference.html#Server_Plug_in_Functionality_Reference-UID_Uniqueness_Plug_in
> >
> > WRT to linux, the only gotcha I can think of is that you''ll
have to set
> > the nss_ldap nss_base_group option in /etc/ldap.conf to an entry
that''s
> > the common parent to both your users and groups - otherwise
it''ll never
> > find the UPG''s.
> >
> >   
> Another way would be to omit the addition of the posixGroup on your 
> account objects, and just modify the filter on nss_base_group to include 
> posixAccounts.
> e.g.:
> nss_base_group  
> dc=example,dc=com?sub?(|(objectClass=posixGroup)(objectClass=posixAccount))
> 
> posixAccount already includes the gidNumber and cn attributes, which is 
> all you''re really after here... unless you want to start adding 
> memberUid attributes to your account objects (which doesn''t make
any
> obvious sense).
> 
> You will almost certainly have to modify your nss_base_group setting in 
> either case, as Jonathan suggested.
> 
<snip>
That''s what I had first attempted to do but I do not see where to set
that filter.  I didn''t see anything in ldap.conf or nsswitch.conf.
Where is it set? Thanks - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

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

John A. Sullivan III wrote:
> On Thu, 2008-11-20 at 09:01 -0800, George Holbert wrote:
>   
>> Jonathan Barber wrote:
>>     
>>> On Wed, Nov 19, 2008 at 03:32:28PM -0500, 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:
>>>>>>>           
>>>>>>>               
>>> [snip]
>>>
>>>   
>>>       
>>>> <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.
>>>>     
>>>>         
>>> This arrangement is known (at least by Redhat) as User Private
Groups
>>> (UPG):
>>>
http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/ref-guide/s1-users-groups-private-groups.html
>>>
>>> The primary reason for doing it is that group access to files is
managed
>>> via secondary group membership, not primary group membership
>>>
>>> If each of your users has their own group, then adding a posixGroup
>>> objectclass to each user makes perfect sense. You may also want to
place
>>> an uniqueness constraint on the gidNumber attribute as well:
>>>
http://www.centos.org/docs/5/html/CDS/ag/8.0/Administering_DSPPR-Server_Plug_in_Functionality_Reference.html#Server_Plug_in_Functionality_Reference-UID_Uniqueness_Plug_in
>>>
>>> WRT to linux, the only gotcha I can think of is that
you''ll have to set
>>> the nss_ldap nss_base_group option in /etc/ldap.conf to an entry
that''s
>>> the common parent to both your users and groups - otherwise
it''ll never
>>> find the UPG''s.
>>>
>>>   
>>>       
>> Another way would be to omit the addition of the posixGroup on your 
>> account objects, and just modify the filter on nss_base_group to
include
>> posixAccounts.
>> e.g.:
>> nss_base_group  
>>
dc=example,dc=com?sub?(|(objectClass=posixGroup)(objectClass=posixAccount))
>>
>> posixAccount already includes the gidNumber and cn attributes, which is
>> all you''re really after here... unless you want to start
adding
>> memberUid attributes to your account objects (which doesn''t
make any
>> obvious sense).
>>
>> You will almost certainly have to modify your nss_base_group setting in
>> either case, as Jonathan suggested.
>>
>>     
> <snip>
> That''s what I had first attempted to do but I do not see where to
set
> that filter.  I didn''t see anything in ldap.conf or nsswitch.conf.
> Where is it set? Thanks - John
>   
/etc/ldap.conf - do man nss_ldap - look for this:
       nss_base_<map> <basedn?scope?filter>
              Specify the search base, scope and filter to be  used  
for  spe-
              cific  maps. (Note that map forms part of the 
configuration file
...

On Thu, 2008-11-20 at 09:01 -0800, George Holbert wrote:
> Jonathan Barber wrote:
> > On Wed, Nov 19, 2008 at 03:32:28PM -0500, 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:
> >>>>>           
> >
> > [snip]
> >
> >   
> >> <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.
> >>     
> >
> > This arrangement is known (at least by Redhat) as User Private Groups
> > (UPG):
> >
http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/ref-guide/s1-users-groups-private-groups.html
> >
> > The primary reason for doing it is that group access to files is
managed
> > via secondary group membership, not primary group membership
> >
> > If each of your users has their own group, then adding a posixGroup
> > objectclass to each user makes perfect sense. You may also want to
place
> > an uniqueness constraint on the gidNumber attribute as well:
> >
http://www.centos.org/docs/5/html/CDS/ag/8.0/Administering_DSPPR-Server_Plug_in_Functionality_Reference.html#Server_Plug_in_Functionality_Reference-UID_Uniqueness_Plug_in
> >
> > WRT to linux, the only gotcha I can think of is that you''ll
have to set
> > the nss_ldap nss_base_group option in /etc/ldap.conf to an entry
that''s
> > the common parent to both your users and groups - otherwise
it''ll never
> > find the UPG''s.
> >
> >   
> Another way would be to omit the addition of the posixGroup on your 
> account objects, and just modify the filter on nss_base_group to include 
> posixAccounts.
> e.g.:
> nss_base_group  
> dc=example,dc=com?sub?(|(objectClass=posixGroup)(objectClass=posixAccount))
> 
> posixAccount already includes the gidNumber and cn attributes, which is 
> all you''re really after here... unless you want to start adding 
> memberUid attributes to your account objects (which doesn''t make
any
> obvious sense).
> 
> You will almost certainly have to modify your nss_base_group setting in 
> either case, as Jonathan suggested.
> 
<snip>
Alas, I''m not sure this is going to work as expected but it could be my
ignorance.  I''ve read the man page and whatever documentation I could
find.  It appears it does an & operation with the additional filter
whereas I need an |.

I gather the default is:
&(objectClass=posixgroup)(cn=group_name)

I think I need it to be:
|((&(objectClass=posixgroup)(cn=group_name))(&(objectClass=posixaccount)(uid=group_name)))

If it does an &, I think I get:
&((&(objectClass=posixgroup)(cn=group_name))(&(objectClass=posixaccount)(uid=group_name)))

Nevertheless, I tried all of the following without success:

nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?|(objectClass=posixAccount)

nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?|(&(objectClass=posixAccount)(uid=group_name))
this broke the posixgroup filter, too!

nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?&(objectClass=posixAccount)(uid=group_name)
this broke the posixgroup filter, too!

nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?(objectClass=posixAccount)(uid=group_name)
this broke the posixgroup filter, too!

nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?(objectClass=posixAccount)
this broke the posixgroup filter, too!

nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?&(objectClass=posixAccount)

I did flush the nscd group database between each try.  What am I doing
wrong? Thanks - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

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

John A. Sullivan III wrote:
> On Thu, 2008-11-20 at 09:01 -0800, George Holbert wrote:
>   
>> Jonathan Barber wrote:
>>     
>>> On Wed, Nov 19, 2008 at 03:32:28PM -0500, 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:
>>>>>>>           
>>>>>>>               
>>> [snip]
>>>
>>>   
>>>       
>>>> <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.
>>>>     
>>>>         
>>> This arrangement is known (at least by Redhat) as User Private
Groups
>>> (UPG):
>>>
http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/ref-guide/s1-users-groups-private-groups.html
>>>
>>> The primary reason for doing it is that group access to files is
managed
>>> via secondary group membership, not primary group membership
>>>
>>> If each of your users has their own group, then adding a posixGroup
>>> objectclass to each user makes perfect sense. You may also want to
place
>>> an uniqueness constraint on the gidNumber attribute as well:
>>>
http://www.centos.org/docs/5/html/CDS/ag/8.0/Administering_DSPPR-Server_Plug_in_Functionality_Reference.html#Server_Plug_in_Functionality_Reference-UID_Uniqueness_Plug_in
>>>
>>> WRT to linux, the only gotcha I can think of is that
you''ll have to set
>>> the nss_ldap nss_base_group option in /etc/ldap.conf to an entry
that''s
>>> the common parent to both your users and groups - otherwise
it''ll never
>>> find the UPG''s.
>>>
>>>   
>>>       
>> Another way would be to omit the addition of the posixGroup on your 
>> account objects, and just modify the filter on nss_base_group to
include
>> posixAccounts.
>> e.g.:
>> nss_base_group  
>>
dc=example,dc=com?sub?(|(objectClass=posixGroup)(objectClass=posixAccount))
>>
>> posixAccount already includes the gidNumber and cn attributes, which is
>> all you''re really after here... unless you want to start
adding
>> memberUid attributes to your account objects (which doesn''t
make any
>> obvious sense).
>>
>> You will almost certainly have to modify your nss_base_group setting in
>> either case, as Jonathan suggested.
>>
>>     
> <snip>
> Alas, I''m not sure this is going to work as expected but it could
be my
> ignorance.  I''ve read the man page and whatever documentation I
could
> find.  It appears it does an & operation with the additional filter
> whereas I need an |.
>
> I gather the default is:
> &(objectClass=posixgroup)(cn=group_name)
>
> I think I need it to be:
>
|((&(objectClass=posixgroup)(cn=group_name))(&(objectClass=posixaccount)(uid=group_name)))
>
> If it does an &, I think I get:
>
&((&(objectClass=posixgroup)(cn=group_name))(&(objectClass=posixaccount)(uid=group_name)))
>
> Nevertheless, I tried all of the following without success:
>
> nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?|(objectClass=posixAccount)
>
> nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?|(&(objectClass=posixAccount)(uid=group_name))
> this broke the posixgroup filter, too!
>
> nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?&(objectClass=posixAccount)(uid=group_name)
> this broke the posixgroup filter, too!
>
> nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?(objectClass=posixAccount)(uid=group_name)
> this broke the posixgroup filter, too!
>
> nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?(objectClass=posixAccount)
> this broke the posixgroup filter, too!
>
> nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?&(objectClass=posixAccount)
>
> I did flush the nscd group database between each try.  What am I doing
> wrong? Thanks - John
>   
It''s not immediately obvious to me where the problem is.
But, have you tried reviewing your LDAP server''s access log?
That''s often a huge help for troubleshooting this kind of thing.

On Thu, 2008-11-20 at 14:43 -0800, George Holbert wrote:
> John A. Sullivan III wrote:
> > On Thu, 2008-11-20 at 09:01 -0800, George Holbert wrote:
> >   
> >> Jonathan Barber wrote:
> >>     
> >>> On Wed, Nov 19, 2008 at 03:32:28PM -0500, 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:
> >>>>>>>           
> >>>>>>>               
> >>> [snip]
> >>>
> >>>   
> >>>       
> >>>> <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.
> >>>>     
> >>>>         
> >>> This arrangement is known (at least by Redhat) as User Private
Groups
> >>> (UPG):
> >>>
http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/ref-guide/s1-users-groups-private-groups.html
> >>>
> >>> The primary reason for doing it is that group access to files
is managed
> >>> via secondary group membership, not primary group membership
> >>>
> >>> If each of your users has their own group, then adding a
posixGroup
> >>> objectclass to each user makes perfect sense. You may also
want to place
> >>> an uniqueness constraint on the gidNumber attribute as well:
> >>>
http://www.centos.org/docs/5/html/CDS/ag/8.0/Administering_DSPPR-Server_Plug_in_Functionality_Reference.html#Server_Plug_in_Functionality_Reference-UID_Uniqueness_Plug_in
> >>>
> >>> WRT to linux, the only gotcha I can think of is that
you''ll have to set
> >>> the nss_ldap nss_base_group option in /etc/ldap.conf to an
entry that''s
> >>> the common parent to both your users and groups - otherwise
it''ll never
> >>> find the UPG''s.
> >>>
> >>>   
> >>>       
> >> Another way would be to omit the addition of the posixGroup on
your
> >> account objects, and just modify the filter on nss_base_group to
include
> >> posixAccounts.
> >> e.g.:
> >> nss_base_group  
> >>
dc=example,dc=com?sub?(|(objectClass=posixGroup)(objectClass=posixAccount))
> >>
> >> posixAccount already includes the gidNumber and cn attributes,
which is
> >> all you''re really after here... unless you want to start
adding
> >> memberUid attributes to your account objects (which
doesn''t make any
> >> obvious sense).
> >>
> >> You will almost certainly have to modify your nss_base_group
setting in
> >> either case, as Jonathan suggested.
> >>
> >>     
> > <snip>
> > Alas, I''m not sure this is going to work as expected but it
could be my
> > ignorance.  I''ve read the man page and whatever documentation
I could
> > find.  It appears it does an & operation with the additional
filter
> > whereas I need an |.
> >
> > I gather the default is:
> > &(objectClass=posixgroup)(cn=group_name)
> >
> > I think I need it to be:
> >
|((&(objectClass=posixgroup)(cn=group_name))(&(objectClass=posixaccount)(uid=group_name)))
> >
> > If it does an &, I think I get:
> >
&((&(objectClass=posixgroup)(cn=group_name))(&(objectClass=posixaccount)(uid=group_name)))
> >
> > Nevertheless, I tried all of the following without success:
> >
> > nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?|(objectClass=posixAccount)
> >
> > nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?|(&(objectClass=posixAccount)(uid=group_name))
> > this broke the posixgroup filter, too!
> >
> > nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?&(objectClass=posixAccount)(uid=group_name)
> > this broke the posixgroup filter, too!
> >
> > nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?(objectClass=posixAccount)(uid=group_name)
> > this broke the posixgroup filter, too!
> >
> > nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?(objectClass=posixAccount)
> > this broke the posixgroup filter, too!
> >
> > nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?&(objectClass=posixAccount)
> >
> > I did flush the nscd group database between each try.  What am I doing
> > wrong? Thanks - John
> >   
> It''s not immediately obvious to me where the problem is.
> But, have you tried reviewing your LDAP server''s access log?
> That''s often a huge help for troubleshooting this kind of thing.
<snip>
Thanks.  I do see what it is doing but I''m still not sure how to
configure the nss_base_group for two reasons which I''ll state in a
second.  Here is a query when I do an ls -l on a directory so it needs
to resolve the gidnumber to a group name:

filter="(&(objectClass=posixGroup)(gidNumber=103000)(|(&(objectClass=posixAccount)(gidNumber=group_number))))"

This is what happens if I try to do a chgrp and it thus needs to resolve
a name to a number:

filter="(&(objectClass=posixGroup)(cn=barry.knowles)(|(&(objectClass=posixAccount))))"

The first question is where to find the variables which are replaced by
the actual values.  You can see I guessed at group_number in the first
case and was wrong.  How do I build a filter which will substitute
103000 when I am seeking that particular gidnumber?

The second question is the sought attribute seems to vary depending on
the function.  How do I create the filter to search on gidnumber in the
first case and cn in the second?

Sorry if I''m being dense.  I''m quite new to all this - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

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

John A. Sullivan III wrote:
> On Thu, 2008-11-20 at 09:01 -0800, George Holbert wrote:
>   
>> Jonathan Barber wrote:
>>     
>>> On Wed, Nov 19, 2008 at 03:32:28PM -0500, 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:
>>>>>>>           
>>>>>>>               
>>> [snip]
>>>
>>>   
>>>       
>>>> <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.
>>>>     
>>>>         
>>> This arrangement is known (at least by Redhat) as User Private
Groups
>>> (UPG):
>>>
http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/ref-guide/s1-users-groups-private-groups.html
>>>
>>> The primary reason for doing it is that group access to files is
managed
>>> via secondary group membership, not primary group membership
>>>
>>> If each of your users has their own group, then adding a posixGroup
>>> objectclass to each user makes perfect sense. You may also want to
place
>>> an uniqueness constraint on the gidNumber attribute as well:
>>>
http://www.centos.org/docs/5/html/CDS/ag/8.0/Administering_DSPPR-Server_Plug_in_Functionality_Reference.html#Server_Plug_in_Functionality_Reference-UID_Uniqueness_Plug_in
>>>
>>> WRT to linux, the only gotcha I can think of is that
you''ll have to set
>>> the nss_ldap nss_base_group option in /etc/ldap.conf to an entry
that''s
>>> the common parent to both your users and groups - otherwise
it''ll never
>>> find the UPG''s.
>>>
>>>   
>>>       
>> Another way would be to omit the addition of the posixGroup on your 
>> account objects, and just modify the filter on nss_base_group to
include
>> posixAccounts.
>> e.g.:
>> nss_base_group  
>>
dc=example,dc=com?sub?(|(objectClass=posixGroup)(objectClass=posixAccount))
>>
>> posixAccount already includes the gidNumber and cn attributes, which is
>> all you''re really after here... unless you want to start
adding
>> memberUid attributes to your account objects (which doesn''t
make any
>> obvious sense).
>>
>> You will almost certainly have to modify your nss_base_group setting in
>> either case, as Jonathan suggested.
>>
>>     
> <snip>
> Alas, I''m not sure this is going to work as expected but it could
be my
> ignorance.  I''ve read the man page and whatever documentation I
could
> find.  It appears it does an & operation with the additional filter
> whereas I need an |.
>
> I gather the default is:
> &(objectClass=posixgroup)(cn=group_name)
>
> I think I need it to be:
>
|((&(objectClass=posixgroup)(cn=group_name))(&(objectClass=posixaccount)(uid=group_name)))
>
> If it does an &, I think I get:
>
&((&(objectClass=posixgroup)(cn=group_name))(&(objectClass=posixaccount)(uid=group_name)))
>
> Nevertheless, I tried all of the following without success:
>
> nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?|(objectClass=posixAccount)
>   
Invalid filter - the "|" character does not belong
there.
> nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?|(&(objectClass=posixAccount)(uid=group_name))
> this broke the posixgroup filter, too!
>   
Also invalid - "|" character
> nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?&(objectClass=posixAccount)(uid=group_name)
> this broke the posixgroup filter, too!
>   
Invalid filter - a filter must begin with ( and end with ) - so 
(&(objectClass=posixAccount)(uid=group_name))
> nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?(objectClass=posixAccount)(uid=group_name)
> this broke the posixgroup filter, too!
>   
Invalid filter -
(&(objectClass=posixAccount)(uid=group_name))
> nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?(objectClass=posixAccount)
> this broke the posixgroup filter, too!
>   
Not sure what''s wrong with this one - looks ok
> nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?&(objectClass=posixAccount)
>   
Invalid filter - should just be
(objectClass=posixAccount)
> I did flush the nscd group database between each try.  What am I doing
> wrong? Thanks - John
>   
It looks as though nss_base_group uses LDAP URL syntax - see 
http://www.ietf.org/rfc/rfc2255.txt for more information about LDAP 
URLs, and http://www.ietf.org/rfc/rfc2254.txt for information about LDAP 
filters

On Fri, 2008-11-21 at 09:10 -0700, Rich Megginson wrote:
> John A. Sullivan III wrote:
> > On Thu, 2008-11-20 at 09:01 -0800, George Holbert wrote:
> >   
> >> Jonathan Barber wrote:
> >>     
> >>> On Wed, Nov 19, 2008 at 03:32:28PM -0500, 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:
> >>>>>>>           
> >>>>>>>               
> >>> [snip]
> >>>
> >>>   
> >>>       
> >>>> <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.
> >>>>     
> >>>>         
> >>> This arrangement is known (at least by Redhat) as User Private
Groups
> >>> (UPG):
> >>>
http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/ref-guide/s1-users-groups-private-groups.html
> >>>
> >>> The primary reason for doing it is that group access to files
is managed
> >>> via secondary group membership, not primary group membership
> >>>
> >>> If each of your users has their own group, then adding a
posixGroup
> >>> objectclass to each user makes perfect sense. You may also
want to place
> >>> an uniqueness constraint on the gidNumber attribute as well:
> >>>
http://www.centos.org/docs/5/html/CDS/ag/8.0/Administering_DSPPR-Server_Plug_in_Functionality_Reference.html#Server_Plug_in_Functionality_Reference-UID_Uniqueness_Plug_in
> >>>
> >>> WRT to linux, the only gotcha I can think of is that
you''ll have to set
> >>> the nss_ldap nss_base_group option in /etc/ldap.conf to an
entry that''s
> >>> the common parent to both your users and groups - otherwise
it''ll never
> >>> find the UPG''s.
> >>>
> >>>   
> >>>       
> >> Another way would be to omit the addition of the posixGroup on
your
> >> account objects, and just modify the filter on nss_base_group to
include
> >> posixAccounts.
> >> e.g.:
> >> nss_base_group  
> >>
dc=example,dc=com?sub?(|(objectClass=posixGroup)(objectClass=posixAccount))
> >>
> >> posixAccount already includes the gidNumber and cn attributes,
which is
> >> all you''re really after here... unless you want to start
adding
> >> memberUid attributes to your account objects (which
doesn''t make any
> >> obvious sense).
> >>
> >> You will almost certainly have to modify your nss_base_group
setting in
> >> either case, as Jonathan suggested.
> >>
> >>     
> > <snip>
> > Alas, I''m not sure this is going to work as expected but it
could be my
> > ignorance.  I''ve read the man page and whatever documentation
I could
> > find.  It appears it does an & operation with the additional
filter
> > whereas I need an |.
> >
> > I gather the default is:
> > &(objectClass=posixgroup)(cn=group_name)
> >
> > I think I need it to be:
> >
|((&(objectClass=posixgroup)(cn=group_name))(&(objectClass=posixaccount)(uid=group_name)))
> >
> > If it does an &, I think I get:
> >
&((&(objectClass=posixgroup)(cn=group_name))(&(objectClass=posixaccount)(uid=group_name)))
> >
> > Nevertheless, I tried all of the following without success:
> >
> > nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?|(objectClass=posixAccount)
> >   
> Invalid filter - the "|" character does not belong there.
> > nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?|(&(objectClass=posixAccount)(uid=group_name))
> > this broke the posixgroup filter, too!
> >   
> Also invalid - "|" character
> > nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?&(objectClass=posixAccount)(uid=group_name)
> > this broke the posixgroup filter, too!
> >   
> Invalid filter - a filter must begin with ( and end with ) - so 
> (&(objectClass=posixAccount)(uid=group_name))
> > nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?(objectClass=posixAccount)(uid=group_name)
> > this broke the posixgroup filter, too!
> >   
> Invalid filter - (&(objectClass=posixAccount)(uid=group_name))
> > nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?(objectClass=posixAccount)
> > this broke the posixgroup filter, too!
> >   
> Not sure what''s wrong with this one - looks ok
> > nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?&(objectClass=posixAccount)
> >   
> Invalid filter - should just be (objectClass=posixAccount)
> > I did flush the nscd group database between each try.  What am I doing
> > wrong? Thanks - John
> >   
> It looks as though nss_base_group uses LDAP URL syntax - see 
> http://www.ietf.org/rfc/rfc2255.txt for more information about LDAP 
> URLs, and http://www.ietf.org/rfc/rfc2254.txt for information about LDAP 
> filters
<snip>
Thanks very much.  The reason I did not have the initial and ending ()
is it appears nss puts them there itself when it does the &.  At least,
that''s the way it looked in the access log.

How does one pass the values to the ldap query, i.e., what the sought cn
or gidnumber is? - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

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

John A. Sullivan III wrote:
> On Fri, 2008-11-21 at 09:10 -0700, Rich Megginson wrote:
>   
>> John A. Sullivan III wrote:
>>     
>>> On Thu, 2008-11-20 at 09:01 -0800, George Holbert wrote:
>>>   
>>>       
>>>> Jonathan Barber wrote:
>>>>     
>>>>         
>>>>> On Wed, Nov 19, 2008 at 03:32:28PM -0500, 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:
>>>>>>>>>           
>>>>>>>>>               
>>>>>>>>>                   
>>>>> [snip]
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>>>> <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.
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> This arrangement is known (at least by Redhat) as User
Private Groups
>>>>> (UPG):
>>>>>
http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/ref-guide/s1-users-groups-private-groups.html
>>>>>
>>>>> The primary reason for doing it is that group access to
files is managed
>>>>> via secondary group membership, not primary group
membership
>>>>>
>>>>> If each of your users has their own group, then adding a
posixGroup
>>>>> objectclass to each user makes perfect sense. You may also
want to place
>>>>> an uniqueness constraint on the gidNumber attribute as
well:
>>>>>
http://www.centos.org/docs/5/html/CDS/ag/8.0/Administering_DSPPR-Server_Plug_in_Functionality_Reference.html#Server_Plug_in_Functionality_Reference-UID_Uniqueness_Plug_in
>>>>>
>>>>> WRT to linux, the only gotcha I can think of is that
you''ll have to set
>>>>> the nss_ldap nss_base_group option in /etc/ldap.conf to an
entry that''s
>>>>> the common parent to both your users and groups - otherwise
it''ll never
>>>>> find the UPG''s.
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>> Another way would be to omit the addition of the posixGroup on
your
>>>> account objects, and just modify the filter on nss_base_group
to include
>>>> posixAccounts.
>>>> e.g.:
>>>> nss_base_group  
>>>>
dc=example,dc=com?sub?(|(objectClass=posixGroup)(objectClass=posixAccount))
>>>>
>>>> posixAccount already includes the gidNumber and cn attributes,
which is
>>>> all you''re really after here... unless you want to
start adding
>>>> memberUid attributes to your account objects (which
doesn''t make any
>>>> obvious sense).
>>>>
>>>> You will almost certainly have to modify your nss_base_group
setting in
>>>> either case, as Jonathan suggested.
>>>>
>>>>     
>>>>         
>>> <snip>
>>> Alas, I''m not sure this is going to work as expected but
it could be my
>>> ignorance.  I''ve read the man page and whatever
documentation I could
>>> find.  It appears it does an & operation with the additional
filter
>>> whereas I need an |.
>>>
>>> I gather the default is:
>>> &(objectClass=posixgroup)(cn=group_name)
>>>
>>> I think I need it to be:
>>>
|((&(objectClass=posixgroup)(cn=group_name))(&(objectClass=posixaccount)(uid=group_name)))
>>>
>>> If it does an &, I think I get:
>>>
&((&(objectClass=posixgroup)(cn=group_name))(&(objectClass=posixaccount)(uid=group_name)))
>>>
>>> Nevertheless, I tried all of the following without success:
>>>
>>> nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?|(objectClass=posixAccount)
>>>   
>>>       
>> Invalid filter - the "|" character does not belong there.
>>     
>>> nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?|(&(objectClass=posixAccount)(uid=group_name))
>>> this broke the posixgroup filter, too!
>>>   
>>>       
>> Also invalid - "|" character
>>     
>>> nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?&(objectClass=posixAccount)(uid=group_name)
>>> this broke the posixgroup filter, too!
>>>   
>>>       
>> Invalid filter - a filter must begin with ( and end with ) - so 
>> (&(objectClass=posixAccount)(uid=group_name))
>>     
>>> nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?(objectClass=posixAccount)(uid=group_name)
>>> this broke the posixgroup filter, too!
>>>   
>>>       
>> Invalid filter - (&(objectClass=posixAccount)(uid=group_name))
>>     
>>> nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?(objectClass=posixAccount)
>>> this broke the posixgroup filter, too!
>>>   
>>>       
>> Not sure what''s wrong with this one - looks ok
>>     
>>> nss_base_group         
dc=X,dc=com,dc=ssiservices,dc=biz?sub?&(objectClass=posixAccount)
>>>   
>>>       
>> Invalid filter - should just be (objectClass=posixAccount)
>>     
>>> I did flush the nscd group database between each try.  What am I
doing
>>> wrong? Thanks - John
>>>   
>>>       
>> It looks as though nss_base_group uses LDAP URL syntax - see 
>> http://www.ietf.org/rfc/rfc2255.txt for more information about LDAP 
>> URLs, and http://www.ietf.org/rfc/rfc2254.txt for information about
LDAP
>> filters
>>     
> <snip>
> Thanks very much.  The reason I did not have the initial and ending ()
> is it appears nss puts them there itself when it does the &.  At least,
> that''s the way it looked in the access log.
>   
Hmm - dunno
> How does one pass the values to the ldap query, i.e., what the sought cn
> or gidnumber is? - John
>   
I suppose getent/nss_ldap does that automatically - check the access log 
on the directory server.