posixgroup name lookups

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

 



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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3258 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20081121/578bb3e0/attachment.bin 


[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux