On Sun, 2008-10-05 at 16:31 -0500, Aaron Griffin wrote:

On Sun, Oct 5, 2008 at 7:35 AM, Roman Kyrylych wrote:

...

2008/9/27 Dan McGee :

...

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.

On Sun, Oct 5, 2008 at 5:45 PM, Aaron Griffin wrote:

On Sun, Oct 5, 2008 at 5:06 PM, Jan de Groot wrote:

...

On Sun, 2008-10-05 at 16:31 -0500, Aaron Griffin wrote:

...

On Sun, Oct 5, 2008 at 7:35 AM, Roman Kyrylych wrote:

...

2008/9/27 Dan McGee :

...

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