Difference between revisions of "Talk:DeveloperWiki:UID / GID Database"

From ArchWiki
Jump to navigation Jump to search
(add lightdm info)
(The sudo group is missing. Other distros have this gid set to 27: re)
 
(47 intermediate revisions by 11 users not shown)
Line 1: Line 1:
 +
{{Note|'''Moderation''': [[AUR]] packages are unsupported content. This page is about packages in the [[official repositories]]. If you wish to reserve groups, or otherwise request features, use the bugtracker: https://bugs.archlinux.org/. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:11, 17 March 2016 (UTC)}}
 +
 +
== Create users at build time ==
 +
 
Why should user and group be created at build time? This sounds really weird to me.
 
Why should user and group be created at build time? This sounds really weird to me.
 
Arch packages aren't supposed to be shared? You can very well build a package and not install it immediately.
 
Arch packages aren't supposed to be shared? You can very well build a package and not install it immediately.
Line 21: Line 25:
 
EDIT: 91 is used for video apparently, changed to 97
 
EDIT: 91 is used for video apparently, changed to 97
  
== xbmc ==
+
== kodi ==
  
 
Before the xbmc package just created a system user and in the install script it always did a chown to make sure the /var/lib/xbmc folder was owned by xbmc.
 
Before the xbmc package just created a system user and in the install script it always did a chown to make sure the /var/lib/xbmc folder was owned by xbmc.
Line 28: Line 32:
  
 
Could someone add the xbmc uid and gid to the list?
 
Could someone add the xbmc uid and gid to the list?
 +
 +
:Now {{Pkg|kodi}}. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:13, 23 October 2015 (UTC)
  
 
== lightdm ==
 
== lightdm ==
Line 42: Line 48:
 
</nowiki>}}
 
</nowiki>}}
  
== AUR ==
+
== Reserve UID/GID for system administrators? ==
 +
 
 +
Standardization of UID/GID is nice thing but currently I believe it is assigned randomly based on package maintainer request.
 +
 
 +
I need to create 2-3 system users on many machines where assumption is UID/GID will be same in all machines.
 +
 
 +
But I fear that in future Arch may allocate that UID/GID to some "new" popular package.
  
=== What about packages from AUR? ===
+
Because in that case then I will have to change UID/GID of my system users on all machines as well as chown all files owned by those UID/GID.
  
As I started discussing it at [[Talk:Arch_Packaging_Standards#Adding_system_users]], it would be good to have a clearer process for the addition of system users, and maybe a specific sub-namespace (_e.g._ from 500 to 749) for AUR, as well as some authoritative list to avoid collisions ? Maybe another namespace (750-999?) should also be kept strictly reserved for local uses, so admins can create groups knowing that no upstream ArchLinux package will ever use the ID.
+
So if we can reserve some fifty to hundred UIDs (say from 800 to 850 OR 800 to 900) for system adminitrator's use only, then it would be nice for administrators like me.
  
=== Ossec ===
+
[[User:Amish|Amish]] ([[User talk:Amish|talk]]) 16:36, 21 May 2017 (UTC)
  
# grep ossec /etc/group
+
:Is this right place for discussing this?
## ossec:x:525:
+
:
# grep ossec /etc/passwd
+
:This is something like systemd where /usr is used for defaults and /etc is used for system administrators so as to avoid conflicts
## ossec:x:524:525::/var/ossec:/bin/false
+
:
## ossecm:x:525:525::/var/ossec:/bin/false
+
:Sameway UID/GID from 800 to 850/900 can be reserved to be used by system administrators without worrying that it would be used by some other package in future and create conflict.
## ossecr:x:526:525::/var/ossec:/bin/false
+
:
 +
:[[User:Amish|Amish]] ([[User talk:Amish|talk]]) 04:56, 16 August 2017 (UTC)
  
 +
::As you can see from the list, Arch has reserved less than 1000 UIDs out of [https://serverfault.com/questions/105260/how-big-in-bits-is-a-unix-uid some very large number]. ''useradd'' assigns UIDs from 1000 to 60000 and [[systemd-nspawn]] uses UIDs larger than 65536 for [[systemd-nspawn#Creating private users (unprivileged containers)|unprivileged containers]]. So if you use UIDs around 60000 for your own purposes, there is very good chance that it won't conflict with anything. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:22, 16 August 2017 (UTC)
  
thanks :)
+
:::Thank you but system UID/GID are defined by SYS_UID_MIN (500) and SYS_UID_MAX (999) (defined in /etc/login.defs) and some tools use those numbers to differentiate between system user and normal user. (and warn if system user is being deleted) Reserving range of system UID/GID for administrator use, helps for coders who develop their own daemons and want to make sure that in future UID/GID do not conflict.
 +
:::[[User:Amish|Amish]] ([[User talk:Amish|talk]]) 09:55, 16 August 2017 (UTC)
  
=== socket-sentry ===
+
== GIDs are now generated dynamically / the static GIDs here are not valid anymore ==
  
Please add socketsentry group (gid 172) for kdeplasma-addons-applets-socketsentry package ([https://aur.archlinux.org/packages.php?ID=36213]).
+
After recent changes to the filesystem package GIDs are now created by sysusers.d(5). The means, that for example the "users" group does not have a static id of 100 anymore. So, the information here is outdated and needs to be updated to reflect the dynamic id allocation. Either that, or there is a possibilty to set static user ids with sysusers.d, but I haven't investigated this yet.
  
:As you can see, this discussion page doesn't get many replies from developers, you may want to use the forum or the mailing lists for this kind of requests. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:54, 17 June 2012 (UTC)
+
[[User:Jrk|Jrk]] ([[User talk:Jrk|talk]]) 11:50, 14 December 2017 (UTC)
  
=== oml2 entries ===
+
: I'm not following this argument: just because GIDs are created by sysusers.d, why does this mean the users group doesn't have a static id any more? [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 11:21, 18 March 2019 (UTC)
  
Please add oml2 user and group (both 137, arbitrarily, on a Debian system I have at hand). I'm updating the package at https://aur.archlinux.org /packages.php?ID=60321 and https://aur.archlinux.org/packages.php?ID=60322, creating these in the post_install script.
+
::Because systemd's [https://github.com/systemd/systemd/blob/master/sysusers.d/basic.conf.in basic.conf] does not specify the GIDs for most of the groups and Arch's PKGBUILD leaves the configurable values to the default, which leads to dynamic behaviour even for {{ic|users}}. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:25, 18 March 2019 (UTC)
  
[[User:OlivierMehani|OlivierMehani]] ([[User talk:OlivierMehani|talk]]) 08:49, 15 August 2012 (UTC)
+
== <s>The sudo group is missing.  Other distros have this gid set to 27</s> ==
  
=== input group ===
+
For some reason I'm not able to edit this page, but it would be a good idea to include sudo = 27 as per at least Ubuntu/Debian.  [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 11:24, 18 March 2019 (UTC)
  
Would you mind adding the following group to the list?:
+
:Arch's {{pkg|sudo}} package does not create a {{ic|sudo}} group, other distributions are irrelevant. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:17, 18 March 2019 (UTC)
*input:103
 
I am using this group to allow access to input events for gizmod in AUR.
 
  
=== amanda ===
+
:: Yes, I've wondered about this. Does this have something to do with upstream?  The sudo group is pretty widely used AFAIK to identify sys admins on a system, and the {{ic|/etc/sudoers}} file seems to support this by default:
  
Can we have UID and GID 112 set aside for amanda?
+
    ## Uncomment to allow members of group sudo to execute any command
 +
    # %sudo ALL=(ALL) ALL
  
=== cruisecontrol ===
+
:: Anyway, for the people coming from other distros who are used to having a sudo group, is there any harm in providing guidelines for what the GID should be to be consistent?  Seems like no harm done and useful if included.  Nothing in the page description suggests that something which isn't created by default should be excluded.  If this is the policy, you might want to mention that in order to avoid having to respond to comments like this. [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 12:40, 18 March 2019 (UTC)
  
Please add userid 52 for cruisecontrol package ([https://aur.archlinux.org/packages.php?ID=33508])
+
:::Having policy for something which isn't provided doesn't make sense. Arch has other "sysadmin" groups, see [[Users and groups#User groups]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:51, 18 March 2019 (UTC)

Latest revision as of 13:51, 18 March 2019

Note: Moderation: AUR packages are unsupported content. This page is about packages in the official repositories. If you wish to reserve groups, or otherwise request features, use the bugtracker: https://bugs.archlinux.org/. -- Alad (talk) 17:11, 17 March 2016 (UTC)

Create users at build time

Why should user and group be created at build time? This sounds really weird to me. Arch packages aren't supposed to be shared? You can very well build a package and not install it immediately.

In any cases, I think this task definitively needs to be made at install time. That is why it is always done in scriptlets. Now what you might want to do is somehow unifying this task inside the scriptlets. If that's the case, please add your proposal with the two functions there : FS#10375 and maybe edit the wiki accordingly. --shining 04:42, 19 May 2008 (EDT)

Add svn user and group

Just a suggestion: create/reserve UID 44 and GID 44 for snv user (subversion server)

mailman

Can we have UID and GID 97 set aside for mailman? http://www.list.org

EDIT: 91 is used for video apparently, changed to 97

kodi

Before the xbmc package just created a system user and in the install script it always did a chown to make sure the /var/lib/xbmc folder was owned by xbmc.

Now the folder is owned by uid 420 and gid 420, the chown is only needed when updating from a previous state.

Could someone add the xbmc uid and gid to the list?

Now kodi. -- Alad (talk) 15:13, 23 October 2015 (UTC)

lightdm

The lightdm package uses 620 for it's UID/GUID:

post_install() {
    getent group lightdm > /dev/null 2>&1 || groupadd -g 620 lightdm
    getent passwd lightdm > /dev/null 2>&1 || useradd -c 'Light Display Manager' -u 620 -g lightdm -d /var/lib/lightdm -s /usr/bin/nologin lightdm
    passwd -l lightdm > /dev/null
    systemd-tmpfiles --create /usr/lib/tmpfiles.d/lightdm.conf
}

Reserve UID/GID for system administrators?

Standardization of UID/GID is nice thing but currently I believe it is assigned randomly based on package maintainer request.

I need to create 2-3 system users on many machines where assumption is UID/GID will be same in all machines.

But I fear that in future Arch may allocate that UID/GID to some "new" popular package.

Because in that case then I will have to change UID/GID of my system users on all machines as well as chown all files owned by those UID/GID.

So if we can reserve some fifty to hundred UIDs (say from 800 to 850 OR 800 to 900) for system adminitrator's use only, then it would be nice for administrators like me.

Amish (talk) 16:36, 21 May 2017 (UTC)

Is this right place for discussing this?
This is something like systemd where /usr is used for defaults and /etc is used for system administrators so as to avoid conflicts
Sameway UID/GID from 800 to 850/900 can be reserved to be used by system administrators without worrying that it would be used by some other package in future and create conflict.
Amish (talk) 04:56, 16 August 2017 (UTC)
As you can see from the list, Arch has reserved less than 1000 UIDs out of some very large number. useradd assigns UIDs from 1000 to 60000 and systemd-nspawn uses UIDs larger than 65536 for unprivileged containers. So if you use UIDs around 60000 for your own purposes, there is very good chance that it won't conflict with anything. -- Lahwaacz (talk) 07:22, 16 August 2017 (UTC)
Thank you but system UID/GID are defined by SYS_UID_MIN (500) and SYS_UID_MAX (999) (defined in /etc/login.defs) and some tools use those numbers to differentiate between system user and normal user. (and warn if system user is being deleted) Reserving range of system UID/GID for administrator use, helps for coders who develop their own daemons and want to make sure that in future UID/GID do not conflict.
Amish (talk) 09:55, 16 August 2017 (UTC)

GIDs are now generated dynamically / the static GIDs here are not valid anymore

After recent changes to the filesystem package GIDs are now created by sysusers.d(5). The means, that for example the "users" group does not have a static id of 100 anymore. So, the information here is outdated and needs to be updated to reflect the dynamic id allocation. Either that, or there is a possibilty to set static user ids with sysusers.d, but I haven't investigated this yet.

Jrk (talk) 11:50, 14 December 2017 (UTC)

I'm not following this argument: just because GIDs are created by sysusers.d, why does this mean the users group doesn't have a static id any more? Pgoetz (talk) 11:21, 18 March 2019 (UTC)
Because systemd's basic.conf does not specify the GIDs for most of the groups and Arch's PKGBUILD leaves the configurable values to the default, which leads to dynamic behaviour even for users. -- Lahwaacz (talk) 12:25, 18 March 2019 (UTC)

The sudo group is missing. Other distros have this gid set to 27

For some reason I'm not able to edit this page, but it would be a good idea to include sudo = 27 as per at least Ubuntu/Debian. Pgoetz (talk) 11:24, 18 March 2019 (UTC)

Arch's sudo package does not create a sudo group, other distributions are irrelevant. -- Lahwaacz (talk) 12:17, 18 March 2019 (UTC)
Yes, I've wondered about this. Does this have something to do with upstream? The sudo group is pretty widely used AFAIK to identify sys admins on a system, and the /etc/sudoers file seems to support this by default:
   ## Uncomment to allow members of group sudo to execute any command
   # %sudo ALL=(ALL) ALL
Anyway, for the people coming from other distros who are used to having a sudo group, is there any harm in providing guidelines for what the GID should be to be consistent? Seems like no harm done and useful if included. Nothing in the page description suggests that something which isn't created by default should be excluded. If this is the policy, you might want to mention that in order to avoid having to respond to comments like this. Pgoetz (talk) 12:40, 18 March 2019 (UTC)
Having policy for something which isn't provided doesn't make sense. Arch has other "sysadmin" groups, see Users and groups#User groups. -- Lahwaacz (talk) 13:51, 18 March 2019 (UTC)