Re: pam_group vs. multiple group lines
On 8/22/07, Chuck Swiger [EMAIL PROTECTED] wrote: On Aug 21, 2007, at 2:02 PM, Richard Foulkes wrote: Ok, so how are you supposed to control membership of the wheel group via ldap? Ok, you COULD remove the local wheel entry in /etc/ group, but this would probably be a bad idea if the ldap server were unavailable. You've aptly summarized my thoughts on the matter-- I would not rely on LDAP to provide information about root or the wheel group. That is exactly the gist of my question. Of course I know that a group oneliner is the way to go. However, I saw people suggest splitting groups into multiple lines, if the lines are too long or too many groups per line (something to do with the /etc/group parser, I guess). Anyway, I want the LDAP groups to *augment* system groups. Removing wheel from /etc/group and relying on a complex network service not funny. Besides, it *does* work for file permissions etc. so some basic system calls *do* get this right. Uli ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pam_group vs. multiple group lines
Hi, all! On Wed, Aug 22, 2007 at 09:53:42AM +0200, Ulrich Spoerlein wrote: On 8/22/07, Chuck Swiger [EMAIL PROTECTED] wrote: On Aug 21, 2007, at 2:02 PM, Richard Foulkes wrote: Ok, so how are you supposed to control membership of the wheel group via ldap? Ok, you COULD remove the local wheel entry in /etc/ group, but this would probably be a bad idea if the ldap server were unavailable. You've aptly summarized my thoughts on the matter-- I would not rely on LDAP to provide information about root or the wheel group. That is exactly the gist of my question. Of course I know that a group oneliner is the way to go. However, I saw people suggest splitting groups into multiple lines, if the lines are too long or too many groups per line (something to do with the /etc/group parser, I guess). Anyway, I want the LDAP groups to *augment* system groups. Removing wheel from /etc/group and relying on a complex network service not funny. I've only followed this thread loosely, so I apologize if this has already been stated or if I'm completely missing the point, but here goes: We do not use LDAP yet, but have been using NIS in our internal office network for years. If you use the magic + token to merge your NIS database with the static files for passwd and group information, then _if_ the group entry in the static file does not contain any users _then_ the information from NIS is merged in So you can keep a wheel group around as the _primary_ group for root, toor, whatnot ... and all the additional members that have wheel as an auxiliary group come from NIS. Possibly this works for LDAP, too? IMHO at least it should ;-)) Kind regards, Patrick -- punkt.de GmbH * Vorholzstr. 25 * 76137 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 [EMAIL PROTECTED] http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pam_group vs. multiple group lines
On Wed, 22.08.2007 at 10:28:40 +0200, Patrick M. Hausen wrote: On Wed, Aug 22, 2007 at 09:53:42AM +0200, Ulrich Spoerlein wrote: On 8/22/07, Chuck Swiger [EMAIL PROTECTED] wrote: On Aug 21, 2007, at 2:02 PM, Richard Foulkes wrote: Ok, so how are you supposed to control membership of the wheel group via ldap? Ok, you COULD remove the local wheel entry in /etc/ group, but this would probably be a bad idea if the ldap server were unavailable. You've aptly summarized my thoughts on the matter-- I would not rely on LDAP to provide information about root or the wheel group. That is exactly the gist of my question. Of course I know that a group oneliner is the way to go. However, I saw people suggest splitting groups into multiple lines, if the lines are too long or too many groups per line (something to do with the /etc/group parser, I guess). Anyway, I want the LDAP groups to *augment* system groups. Removing wheel from /etc/group and relying on a complex network service not funny. We do not use LDAP yet, but have been using NIS in our internal office network for years. If you use the magic + token to merge your NIS database with the static files for passwd and group information, then I'm not using the compat setting, my nsswitch.conf contains passwd: files ldap group: files ldap _if_ the group entry in the static file does not contain any users _then_ the information from NIS is merged in So you can keep a wheel group around as the _primary_ group for root, toor, whatnot ... and all the additional members that have wheel as an auxiliary group come from NIS. Possibly this works for LDAP, too? IMHO at least it should ;-)) THANK YOU! It is indeed working for LDAP too. But it fails for sudo(8). Luckily I could replace the %wheel directive with a few user id directives. It's still a shortcoming of some sort and I guess I'll file a PR if noone else has any more information on the issue. getent group now has the following wheel entries % getent group|grep wheel wheel:*:0 wheel:*:0:us,root As I said, su(1) is happy, sudo(8) not yet. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pam_group vs. multiple group lines
On 8/22/07, Ulrich Spoerlein [EMAIL PROTECTED] wrote: On Wed, 22.08.2007 at 10:28:40 +0200, Patrick M. Hausen wrote: On Wed, Aug 22, 2007 at 09:53:42AM +0200, Ulrich Spoerlein wrote: That is exactly the gist of my question. Of course I know that a group oneliner is the way to go. However, I saw people suggest splitting groups into multiple lines, if the lines are too long or too many groups per line (something to do with the /etc/group parser, I guess). Anyway, I want the LDAP groups to *augment* system groups. Removing wheel from /etc/group and relying on a complex network service not funny. We do not use LDAP yet, but have been using NIS in our internal office network for years. If you use the magic + token to merge your NIS database with the static files for passwd and group information, then I'm not using the compat setting, my nsswitch.conf contains passwd: files ldap group: files ldap _if_ the group entry in the static file does not contain any users _then_ the information from NIS is merged in So you can keep a wheel group around as the _primary_ group for root, toor, whatnot ... and all the additional members that have wheel as an auxiliary group come from NIS. Possibly this works for LDAP, too? IMHO at least it should ;-)) THANK YOU! It is indeed working for LDAP too. But it fails for sudo(8). Luckily I could replace the %wheel directive with a few user id directives. It's still a shortcoming of some sort and I guess I'll file a PR if noone else has any more information on the issue. getent group now has the following wheel entries % getent group|grep wheel wheel:*:0 wheel:*:0:us,root As I said, su(1) is happy, sudo(8) not yet. Does the following work for you: passwd: ldap [notfound=return] files group: ldap [notfound=return] files This sets ldap as the authoritative source for users and groups, unless the ldap service is down, then it will use the files for the source (useful when ldap server is down). This will require that you place all of the users/groups into the ldap server. (modified from the nis example in the nsswitch.conf(5) man page) You could also try the following: passwd: ldap files group: ldap [success=continue] files Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pam_group vs. multiple group lines
On Wed, 22.08.2007 at 13:47:43 -0500, Scot Hetzel wrote: Does the following work for you: passwd: ldap [notfound=return] files group: ldap [notfound=return] files This sets ldap as the authoritative source for users and groups, unless the ldap service is down, then it will use the files for the source (useful when ldap server is down). This will require that you place all of the users/groups into the ldap server. (modified from the nis example in the nsswitch.conf(5) man page) Thanks for you suggestion! In the end, I did it the other way round, using: passwd: files ldap group: files [success=continue] ldap This has the effect of merging the multiple group sources into one, as can be seen here % getent group|grep wheel wheel:*:0:root,us I now have to play a little bit with bootup (no LDAP present) and what happens when LDAP goes offline, etc. Thanks again! Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
pam_group vs. multiple group lines
Hi, I think I found a deficiency wrt. to pam_group (which also hits sudo(8) so this might be libc related instead). I found this while trying to migrate groups into LDAP, but you don't need LDAP to reproduce this, simply place the following in /etc/group wheel:*:0:root wheel:*:0:us % getent group|grep wheel;id wheel:*:0:root wheel:*:0:us uid=1001(us) gid=1000(us) groups=1000(us),0(wheel),80(www) As you can see, getent(1) and id(1) work fine. File access also works like expected, except for su(8) (because of pam_group group=wheel in pam.d/su) % su - su: Sorry Combine the wheel entries back into one line and su(8) suddenly starts working again. Same problem hits sudo(8) if your are using a %wheel line. Since there is no pam.d/sudo on my system I think the bug probably lies in libc itself. Is this expected behaviour? I'd classify it as bug ... Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pam_group vs. multiple group lines
On Aug 21, 2007, at 12:50 PM, Ulrich Spoerlein wrote: I found this while trying to migrate groups into LDAP, but you don't need LDAP to reproduce this, simply place the following in /etc/group wheel:*:0:root wheel:*:0:us That's a misconfiguration. From man 5 group: The group field is the group name used for granting file access to users who are members of the group. The gid field is the number associated with the group name. They should both be unique across the system (and ^ often across a group of systems) since they control file access. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pam_group vs. multiple group lines
Ok, so how are you supposed to control membership of the wheel group via ldap? Ok, you COULD remove the local wheel entry in /etc/group, but this would probably be a bad idea if the ldap server were unavailable. I've had a similar problem to this where group names are duplicated across different operating systems (i use gentoo, freebsd and ubuntu on my network) but the gid's are different. For instance the 'audio' group on gentoo has a different gid to the 'audio' group on ubuntu. This would appear to have something to do with nss_base_group configuration option in the ldap.conf file used by nss_ldap and pam_ldap - something to do with the search scope - whereby i can configure the ldap.conf file for one os to look a sub-tree of my groups ou for additional groups specific to that OS - but documentation on the PADL site on this topic is almost non-existant! Can anyone help? On 21 Aug 2007, at 21:24, Chuck Swiger wrote: On Aug 21, 2007, at 12:50 PM, Ulrich Spoerlein wrote: I found this while trying to migrate groups into LDAP, but you don't need LDAP to reproduce this, simply place the following in /etc/group wheel:*:0:root wheel:*:0:us That's a misconfiguration. From man 5 group: The group field is the group name used for granting file access to users who are members of the group. The gid field is the number associated with the group name. They should both be unique across the system (and ^ often across a group of systems) since they control file access. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: pam_group vs. multiple group lines
Try: wheel:*:0:root,us It looks like pam was stopping at the first matching line as you would expect from the man page for the group file. If there is a bug it is in the more liberal interpretation by other software. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ulrich Spoerlein Sent: Wednesday, 22 August 2007 5:51 AM To: [EMAIL PROTECTED] Subject: pam_group vs. multiple group lines Hi, I think I found a deficiency wrt. to pam_group (which also hits sudo(8) so this might be libc related instead). I found this while trying to migrate groups into LDAP, but you don't need LDAP to reproduce this, simply place the following in /etc/group wheel:*:0:root wheel:*:0:us % getent group|grep wheel;id wheel:*:0:root wheel:*:0:us uid=1001(us) gid=1000(us) groups=1000(us),0(wheel),80(www) As you can see, getent(1) and id(1) work fine. File access also works like expected, except for su(8) (because of pam_group group=wheel in pam.d/su) % su - su: Sorry Combine the wheel entries back into one line and su(8) suddenly starts working again. Same problem hits sudo(8) if your are using a %wheel line. Since there is no pam.d/sudo on my system I think the bug probably lies in libc itself. Is this expected behaviour? I'd classify it as bug ... Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pam_group vs. multiple group lines
On Aug 21, 2007, at 2:02 PM, Richard Foulkes wrote: Ok, so how are you supposed to control membership of the wheel group via ldap? Ok, you COULD remove the local wheel entry in /etc/ group, but this would probably be a bad idea if the ldap server were unavailable. You've aptly summarized my thoughts on the matter-- I would not rely on LDAP to provide information about root or the wheel group. I've had a similar problem to this where group names are duplicated across different operating systems (i use gentoo, freebsd and ubuntu on my network) but the gid's are different. For instance the 'audio' group on gentoo has a different gid to the 'audio' group on ubuntu. This would appear to have something to do with nss_base_group configuration option in the ldap.conf file used by nss_ldap and pam_ldap - something to do with the search scope - whereby i can configure the ldap.conf file for one os to look a sub- tree of my groups ou for additional groups specific to that OS - but documentation on the PADL site on this topic is almost non- existant! Can anyone help? The solutions to these problems are somewhat painful; looking into the experience of those using YP/NIS or NetInfo will probably give some insight which applies to using the newfangled directory services (aka LDAP, Active Directory, Open Directory, etc). You can replace the existing flatfile groups with a unified version which your site is happy with across all of the platforms you use, and then use find -nogroup and things like mtree or rsync to reset the permissions appropriately. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
