DeveloperWiki talk:UID / GID Database

From ArchWiki
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)Reply[reply]

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)Reply[reply]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]