[arch-dev-public] policykit install problem

[Dan McGee]

On Sun, Oct 5, 2008 at 5:45 PM, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> On Sun, Oct 5, 2008 at 5:06 PM, Jan de Groot <jan at jgc.homeip.net> wrote:
>> On Sun, 2008-10-05 at 16:31 -0500, Aaron Griffin wrote:
>>> On Sun, Oct 5, 2008 at 7:35 AM, Roman Kyrylych <roman.kyrylych at gmail.com> wrote:
>>> > 2008/9/27 Dan McGee <dpmcgee at gmail.com>:
>>> >> 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