FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 09-27-2008, 12:58 AM
"Dan McGee"
 
Default policykit install problem

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: `policykitolicykit'
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.

-Dan
 
Old 10-05-2008, 12:35 PM
"Roman Kyrylych"
 
Default policykit install problem

2008/9/27 Dan McGee <dpmcgee@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: `policykitolicykit'
> 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 :-/

--
Roman Kyrylych (*оман Кирилич)
 
Old 10-05-2008, 09:31 PM
"Aaron Griffin"
 
Default policykit install problem

On Sun, Oct 5, 2008 at 7:35 AM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
> 2008/9/27 Dan McGee <dpmcgee@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: `policykitolicykit'
>> 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
 
Old 10-05-2008, 10:06 PM
Jan de Groot
 
Default policykit install problem

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@gmail.com> wrote:
> > 2008/9/27 Dan McGee <dpmcgee@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: `policykitolicykit'
> >> 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.
 
Old 10-05-2008, 10:45 PM
"Aaron Griffin"
 
Default policykit install problem

On Sun, Oct 5, 2008 at 5:06 PM, Jan de Groot <jan@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@gmail.com> wrote:
>> > 2008/9/27 Dan McGee <dpmcgee@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: `policykitolicykit'
>> >> 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?
 
Old 10-05-2008, 11:13 PM
"Dan McGee"
 
Default policykit install problem

On Sun, Oct 5, 2008 at 5:45 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
> On Sun, Oct 5, 2008 at 5:06 PM, Jan de Groot <jan@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@gmail.com> wrote:
>>> > 2008/9/27 Dan McGee <dpmcgee@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: `policykitolicykit'
>>> >> 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
 

Thread Tools




All times are GMT. The time now is 02:42 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org