Re: gids assigned non-deterministically
On Mon, 9 Oct 2006 14:39:07 -0500 Peter Samuelson [EMAIL PROTECTED] wrote: [Roberto C. Sanchez] That is a problem if I want to server everything up out of LDAP. There really should be a reserved range, maybe 100-499 of Debian gids, where they are assigned in a predertmined way. I don't think it's a good idea to put system users and groups into LDAP anyway. They are specific to a system. That is no longer a reality with groups like plugdev, powerdev and netdev, which users need to be a member of to be able to get the wonders of automatically mounted usb-sticks, tweakable power management and whatever comes with the utopia stack. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gids assigned non-deterministically
On Tue, Oct 10, 2006 at 09:36:56AM +0200, Tim Dijkstra wrote: That is no longer a reality with groups like plugdev, powerdev and netdev, which users need to be a member of to be able to get the wonders of automatically mounted usb-sticks, tweakable power management and whatever comes with the utopia stack. Then use pam_group to temporarily assign those groups to users. That way the gids can be different on every system, and you can even gain performance by having less groups in LDAP. Especially if you have more than a handful of users (and if you are considering LDAP, I assume you have), groups with hudreds or thousands of members can cause headaches. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gids assigned non-deterministically
On Tue, 10 Oct 2006 11:20:26 +0200 Gabor Gombas [EMAIL PROTECTED] wrote: On Tue, Oct 10, 2006 at 09:36:56AM +0200, Tim Dijkstra wrote: That is no longer a reality with groups like plugdev, powerdev and netdev, which users need to be a member of to be able to get the wonders of automatically mounted usb-sticks, tweakable power management and whatever comes with the utopia stack. Then use pam_group to temporarily assign those groups to users. That way the gids can be different on every system, and you can even gain performance by having less groups in LDAP. Hmm, pam_group doesn't sound to secure to me... what if on one machine gid 110 is www-data and on another plugdev. Then if a user logs in on the second machine it will get access to gid 110, make some suid executable, which on another machine ... Well the nfs mount is nosuid, but still, I find this a bit scary. Especially if you have more than a handful of users (and if you are considering LDAP, I assume you have), groups with hudreds or thousands of members can cause headaches. But this is of course true... grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gids assigned non-deterministically
[Tim Dijkstra] Hmm, pam_group doesn't sound to secure to me... what if on one machine gid 110 is www-data and on another plugdev. Then if a user logs in on the second machine it will get access to gid 110, make some suid executable, which on another machine ... Well the nfs mount is nosuid, but still, I find this a bit scary. You are right. The groups in use on an NFS mounted directory should be the same across all machines. So you should avoid making any files with those gids on NFS-exported file system. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gids assigned non-deterministically
On Mon, Oct 09, 2006 at 10:16:45AM -0400, Roberto C. Sanchez wrote: I guess that if the deployment were on a new network, it would be easier to affect how the gids are assigned, since you would be looking for issues like that. However, for an existing network, this can be more of a problem. Not necessarily. There is no real need to have system GIDs assigned through LDAP. In fact, personally I'd recommend against it. PAM has this wonderful feature called stacking, which means that you can perfectly well use system GIDs from /etc/group, while your locally assigned GIDs can come from LDAP. I know that's how I did stuff when I transitioned my home network to LDAP. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gids assigned non-deterministically
On Tue, Oct 10, 2006 at 11:33:43AM +0200, Tim Dijkstra wrote: Hmm, pam_group doesn't sound to secure to me... what if on one machine gid 110 is www-data and on another plugdev. Then if a user logs in on the second machine it will get access to gid 110, make some suid executable, which on another machine ... This can't happen. Groups are _not_ transferred over remote login. New files are owned by the user's primary group, and _not_ by the supplemental groups (and I really hope you do not want to use 'plugdev' etc. as the primary group for any real user...) Even newgrp does not work with groups granted by pam_group (more precisely, newgrp asks for the group's password, but system groups should be always locked). So I see no way to transfer a locally granted group to another machine. On the other hand, it is true that you should never create files owned by local uids/gids on shared storage. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gids assigned non-deterministically
On Tue, 10 Oct 2006 15:08:29 +0200 Gabor Gombas [EMAIL PROTECTED] wrote: On Tue, Oct 10, 2006 at 11:33:43AM +0200, Tim Dijkstra wrote: Hmm, pam_group doesn't sound to secure to me... what if on one machine gid 110 is www-data and on another plugdev. Then if a user logs in on the second machine it will get access to gid 110, make some suid executable, which on another machine ... This can't happen. Groups are _not_ transferred over remote login. Of course not, that's the whole point. If you dynamically allocate system groups and dynamically make users members of groups. You can get a mess if they both write to a nfs mounted volume. A file that is owned by group 110 can be groups www-data on one and plugdev on the other. New files are owned by the user's primary group, and _not_ by the supplemental groups (and I really hope you do not want to use 'plugdev' etc. as the primary group for any real user...) That's not an argument someone can just 'chown :plugdev' something. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gids assigned non-deterministically
On Tue, Oct 10, 2006 at 11:20:26AM +0200, Gabor Gombas wrote: On Tue, Oct 10, 2006 at 09:36:56AM +0200, Tim Dijkstra wrote: That is no longer a reality with groups like plugdev, powerdev and netdev, which users need to be a member of to be able to get the wonders of automatically mounted usb-sticks, tweakable power management and whatever comes with the utopia stack. Then use pam_group to temporarily assign those groups to users. That way the gids can be different on every system, and you can even gain performance by having less groups in LDAP. How does that work? Do I need to specify that in each client's pam configuration? Or on each system's /etc/group? Especially if you have more than a handful of users (and if you are considering LDAP, I assume you have), groups with hudreds or thousands of members can cause headaches. Yes. Of course, if you have more than a handful of machines, what you are describing is a management nightmare. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: gids assigned non-deterministically
On Tue, Oct 10, 2006 at 12:46:58PM +0200, Wouter Verhelst wrote: On Mon, Oct 09, 2006 at 10:16:45AM -0400, Roberto C. Sanchez wrote: I guess that if the deployment were on a new network, it would be easier to affect how the gids are assigned, since you would be looking for issues like that. However, for an existing network, this can be more of a problem. Not necessarily. There is no real need to have system GIDs assigned through LDAP. In fact, personally I'd recommend against it. PAM has this wonderful feature called stacking, which means that you can perfectly well use system GIDs from /etc/group, while your locally assigned GIDs can come from LDAP. I know that's how I did stuff when I transitioned my home network to LDAP. That is fine for a home network. However, on a network of 1000 workstations, having to specify group memberships on the clients is kind of a pain. All I am trying to say is that Debian should not make it difficult for the admin to implement what he/she wants. Unfortunately, the current system does just that. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: gids assigned non-deterministically
On Tue, Oct 10, 2006 at 11:15:51AM -0400, Roberto C. Sanchez wrote: That is fine for a home network. However, on a network of 1000 workstations, having to specify group memberships on the clients is kind of a pain. It's not different than having to specify what NFS file systems to mount or where the LDAP server is. If you have 1000 workstations, you do not configure them individually, but either install them from one master image (possibly even every day, like in the case of publicly accessible university machines), or have some central configuration/management system (like Quattor). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: gids assigned non-deterministically
On Tue, Oct 10, 2006 at 03:36:20PM +0200, Tim Dijkstra wrote:
That's not an argument someone can just 'chown :plugdev' something.
Crap. I knew I'd overlook something. I think you could still prevent
that with SELinux though :-)
On the other hand I was thinking about if in your case basically all
user needs to be a member of all these groups anyway, then there is no
point in having these groups at all. Just make pmount executable by
anyone, and edit /etc/dbus-1/system.d/{avahi-dbus.conf,hal.conf} and
replace 'policy group=powerdev' etc. with 'policy
context=default' or with 'policy at_console=true'.
Similarly, if all users have read(/write) access to a device because all
users are part of the group owning the device node, then you can just
make that device node a+r(/a+w) and forget about the group.
Of course there may be services running under other uids that you do not
want to give all access humans has; it has to be decided.
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gids assigned non-deterministically
On Tue, 10 Oct 2006 18:10:42 +0200
Gabor Gombas [EMAIL PROTECTED] wrote:
On Tue, Oct 10, 2006 at 03:36:20PM +0200, Tim Dijkstra wrote:
That's not an argument someone can just 'chown :plugdev' something.
Crap. I knew I'd overlook something. I think you could still prevent
that with SELinux though :-)
Have to read up on SELinux some day, but not now;)
On the other hand I was thinking about if in your case basically all
user needs to be a member of all these groups anyway, then there is no
point in having these groups at all. Just make pmount executable by
anyone, and edit /etc/dbus-1/system.d/{avahi-dbus.conf,hal.conf} and
replace 'policy group=powerdev' etc. with 'policy
context=default' or with 'policy at_console=true'.
Similarly, if all users have read(/write) access to a device because all
users are part of the group owning the device node, then you can just
make that device node a+r(/a+w) and forget about the group.
Of course there may be services running under other uids that you do not
want to give all access humans has; it has to be decided.
Yes, that doesn't seem like the right solution.
In any case, I'm kind of happy with my current setup. I was just trying
to point out that pam_group has it draw backs.
grts Tim
signature.asc
Description: PGP signature
gids assigned non-deterministically
I have started working with transitioning a network to LDAP. I am still experimenting with this at home before implementing it for real. This brings me to my concern. It appears that many groups are added to the system willy-nilly. By that I mean, I have one system where part of the /etc/group file looks like this: gdm:x:101: man:x:12: sasl:x:45: ssh:x:102: crontab:x:104: xfntserv:x:103: postfix:x:105: Debian-exim:x:106: uml-net:x:107: messagebus:x:109: logcheck:x:108: lpadmin:x:110: plugdev:*:46: camera:x:111: postdrop:x:112: scanner:x:113: saned:x:114: sword:x:115: On another system, it looks like this: gdm:x:101: sword:x:102: man:x:12: sasl:x:45: ssh:x:103: crontab:x:105: xfntserv:x:104: postfix:x:106: Debian-exim:x:107: messagebus:x:109: logcheck:x:108: lpadmin:x:110: plugdev:*:46: uml-net:x:112: camera:x:113: postdrop:x:114: For instance, on one system the camera group has gid 111 and 113 on the other. That is a problem if I want to server everything up out of LDAP. There really should be a reserved range, maybe 100-499 of Debian gids, where they are assigned in a predertmined way. For example, of package foo wants to create a system group, it would need to first be assigned a gid out of this range. That way, the order in which packages are assigned does not make a difference, as for instance, group camera will always be assigned gid 117, for instance. I'm not sure if such a thing would be feasible or even possible. However, it is a rather significant annoyance to come up with a solution for this that wouldn't take a long time to implement. I guess that if the deployment were on a new network, it would be easier to affect how the gids are assigned, since you would be looking for issues like that. However, for an existing network, this can be more of a problem. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: gids assigned non-deterministically
Roberto C. Sanchez [EMAIL PROTECTED] wrote: I have started working with transitioning a network to LDAP. I am still experimenting with this at home before implementing it for real. This brings me to my concern. It appears that many groups are added to the system willy-nilly. By that I mean, I have one system where part of the /etc/group file looks like this: gdm:x:101: man:x:12: sasl:x:45: ssh:x:102: [...] On another system, it looks like this: gdm:x:101: sword:x:102: [...] For instance, on one system the camera group has gid 111 and 113 on the other. See http://www.at.debian.org/doc/debian-policy/ch-opersys.html#s9.2.2 That is a problem if I want to server everything up out of LDAP. Either install the packages which dynamically add system users on a master machine first and set them up and export them in LDAP (they won't be re-generated on the client machines if the user already is present) or do not keep system users in LDAP. cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gids assigned non-deterministically
[Roberto C. Sanchez] That is a problem if I want to server everything up out of LDAP. There really should be a reserved range, maybe 100-499 of Debian gids, where they are assigned in a predertmined way. I don't think it's a good idea to put system users and groups into LDAP anyway. They are specific to a system. There is nothing wrong with having regular users and groups in LDAP and system users and groups in /etc/passwd. This is, in fact, probably the common case. signature.asc Description: Digital signature
Re: gids assigned non-deterministically
On Mon, Oct 09, 2006 at 07:09:14PM +0200, Andreas Metzler wrote: Roberto C. Sanchez [EMAIL PROTECTED] wrote: I have started working with transitioning a network to LDAP. I am still experimenting with this at home before implementing it for real. This brings me to my concern. It appears that many groups are added to the system willy-nilly. By that I mean, I have one system where part of the /etc/group file looks like this: gdm:x:101: man:x:12: sasl:x:45: ssh:x:102: [...] On another system, it looks like this: gdm:x:101: sword:x:102: [...] For instance, on one system the camera group has gid 111 and 113 on the other. See http://www.at.debian.org/doc/debian-policy/ch-opersys.html#s9.2.2 I will take a look at this. That is a problem if I want to server everything up out of LDAP. Either install the packages which dynamically add system users on a master machine first and set them up and export them in LDAP (they won't be re-generated on the client machines if the user already is present) or do not keep system users in LDAP. You mention users, but does the same work for groups? If so, I can just whip up a quick script using `find / -group $foo` for all the groups whose gids I want to harmonize. Once that finishes, I can just export the groups via LDAP and remove them entirely from the local machines. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: gids assigned non-deterministically
On Mon, Oct 09, 2006 at 02:39:07PM -0500, Peter Samuelson wrote: [Roberto C. Sanchez] That is a problem if I want to server everything up out of LDAP. There really should be a reserved range, maybe 100-499 of Debian gids, where they are assigned in a predertmined way. I don't think it's a good idea to put system users and groups into LDAP anyway. They are specific to a system. There is nothing wrong with having regular users and groups in LDAP and system users and groups in /etc/passwd. This is, in fact, probably the common case. I do want the system groups in /etc/group. However, I would like to override or supplement the group membership with information out of LDAP. For example, in /etc/group: camera:x:120:foo And then in LDAP, have a group cn=camera,ou=Group,dc=example,dc=org with bar as a member. Assuming that foo is a local user account on the system in question and bar is in the directory, that should work out. I have already tested that and the system sees bar as a member of camera if he logs in. However, the real speed bump in this is that the gids are assigned based on what order the packages are installed. So, camera has gid 120 on one system and 104 on the other. I don't imagine that it is generall a problem, However, if any files are on shared storage and end up bearing the gid of any of these groups where the gids are not uniform across systems, then the user may or may not have access to them based on which machines he is using at the moment. All I am saying, is that there should be some sort of uniformity to it. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
