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
