On Sun, Oct 5, 2008 at 5:45 PM, Aaron Griffin <[EMAIL PROTECTED]> wrote: > On Sun, Oct 5, 2008 at 5:06 PM, Jan de Groot <[EMAIL PROTECTED]> wrote: >> On Sun, 2008-10-05 at 16:31 -0500, Aaron Griffin wrote: >>> On Sun, Oct 5, 2008 at 7:35 AM, Roman Kyrylych <[EMAIL PROTECTED]> wrote: >>> > 2008/9/27 Dan McGee <[EMAIL PROTECTED]>: >>> >> Guys, we have some big problems with groups. >>> >> >>> >> ( 9/31) installing policykit >>> >> [---------------------] 100% >>> >> groupadd: GID 102 is not unique >>> >> useradd: unknown group policykit >>> >> chgrp: invalid group: `policykit' >>> >> chown: invalid user: `policykit' >>> >> chown: invalid user: `policykit:policykit' >>> >> chown: invalid user: `policykit' >>> >> chgrp: invalid group: `policykit' >>> >> chgrp: invalid group: `policykit' >>> >> chgrp: invalid group: `policykit' >>> >> chgrp: invalid group: `policykit' >>> >> chgrp: invalid group: `policykit' >>> >> >>> >> Taking a peek at /etc/groups I saw this: >>> >> >>> >> kvm:x:101: >>> >> tex:x:102: >>> >> >>> >> We really shouldn't be creating groups above 100, should we? Even more >>> >> of a problem is explicitly specifying 102 in the policykit install >>> >> script. These are reserved for user use. Your input is definitely >>> >> welcome on this. >>> > >>> > http://bugs.archlinux.org/task/11589 >>> > >>> > We have user UIDs starting from 1000, but GIDs only from 100. >>> > The most correct would be to have user-created GIDs start from 1000 too, >>> > but then users that already have created 1xx groups should recreate >>> > them and re-chgrp all files/dirs :-/ >>> >>> Mind filing a FR for that? I believe it would require changes in >>> shadow... but we need to be careful to warn all users to modify their >>> custom groups. It will be a headache, but I agree we should do it >> >> Ehm, why do we get ourselves in trouble like this? >> We have an amount of static uid/gid combinations. UIDs below 1000 have >> been reserved for system things for a long while, GIDs below 100 have >> been reserved for system things also. >> We've been using static UID/GIDs in packages for now. This has always >> brought up weird issues with people that have other users using these >> UID/GID combinations. >> When I take a look at the Debian boxes I maintain, I see these groups: >> crontab:x:101: >> ssh:x:102: >> ntp:x:103: >> ssl-cert:x:104: >> postfix:x:105: >> postdrop:x:106: >> >> When I look on a different debian box, I see these numbers are in a >> different order, or different users assigned to these GIDs. I think it's >> better to change packages like policykit instead to add groups and >> change ownership and permission in post_install and post_upgrade. > > Are you suggesting we actually forget about reserved GIDs and UIDs > altogether and do it all dynamically? > > That doesn't sound like too bad of an idea. Opinions?
This particular install was an exception- it *insisted* on using 102 rather than just taking the first available. I feel like our current group policy creates base system groups (and perhaps those required for core packages) with numbers below 100, and everything else is just first-come, first-serve. -Dan
