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

From ArchWiki
Jump to: navigation, search
(socket-sentry)
m (Reverted edits by Epinephrine (talk) to last revision by Amish)
 
(46 intermediate revisions by 14 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 6: Line 10:
 
Now what you might want to do is somehow unifying this task inside the 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 :
 
If that's the case, please add your proposal with the two functions there :
[http://bugs.archlinux.org/task/10375 FS#10375]
+
[https://bugs.archlinux.org/task/10375 FS#10375]
 
and maybe edit the wiki accordingly.
 
and maybe edit the wiki accordingly.
 
--[[User:Shining|shining]] 04:42, 19 May 2008 (EDT)
 
--[[User:Shining|shining]] 04:42, 19 May 2008 (EDT)
 
== input group ==
 
 
Would you mind adding the following group to the list?:
 
*input:103
 
I am using this group to allow access to input events for gizmod in AUR.
 
  
 
== Add svn user and group ==
 
== Add svn user and group ==
Line 27: Line 25:
 
EDIT: 91 is used for video apparently, changed to 97
 
EDIT: 91 is used for video apparently, changed to 97
  
== gdm group? ==
+
== kodi ==
 
 
It seems gdm creates a group when installing as well.  There's a bug against its current behaviour ([http://bugs.archlinux.org/task/13690 bug 13690]), I really think it should have a group with the same gid as its uid (120).
 
 
 
== policykit is incomplete ==
 
 
 
The UID entry for policykit is missing.  It creates both a user (102) and a group (102), only the latter is mentioned on the page.
 
 
 
== pulseaudio ==
 
 
 
Pulseaudio creates one user (pulse : 130) and three groups (pulse : 130, pulse-access : 131, pulse-rt : 132).
 
 
 
== system-tools-backends ==
 
  
This package creates a user-level group, there's a bug open for this issue ([http://bugs.archlinux.org/task/14787 bug 14787]).
+
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.
  
== amanda ==
+
Now the folder is owned by uid 420 and gid 420, the chown is only needed when updating from a previous state.
  
Can we have UID and GID 112 set aside for amanda?
+
Could someone add the xbmc uid and gid to the list?
  
== cruisecontrol ==
+
:Now {{Pkg|kodi}}. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:13, 23 October 2015 (UTC)
  
Please add userid 52 for cruisecontrol package ([https://aur.archlinux.org/packages.php?ID=33508])
+
== lightdm ==
  
== Ossec ==
+
The lightdm package uses {{ic|620}} for it's UID/GUID:
  
# grep ossec /etc/group
+
{{bc|1=<nowiki>
## ossec:x:525:
+
post_install() {
# grep ossec /etc/passwd
+
    getent group lightdm > /dev/null 2>&1 || groupadd -g 620 lightdm
## ossec:x:524:525::/var/ossec:/bin/false
+
    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
## ossecm:x:525:525::/var/ossec:/bin/false
+
    passwd -l lightdm > /dev/null
## ossecr:x:526:525::/var/ossec:/bin/false
+
    systemd-tmpfiles --create /usr/lib/tmpfiles.d/lightdm.conf
 +
}
 +
</nowiki>}}
  
 +
== Reserve UID/GID for system administrators? ==
  
thanks :)
+
Standardization of UID/GID is nice thing but currently I believe it is assigned randomly based on package maintainer request.
  
== What about packages from AUR? ==
+
I need to create 2-3 system users on many machines where assumption is UID/GID will be same in all machines.
  
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.
+
But I fear that in future Arch may allocate that UID/GID to some "new" popular package.
  
== socket-sentry ==
+
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.
  
Please add socketsentry group (gid 172) for kdeplasma-addons-applets-socketsentry package ([https://aur.archlinux.org/packages.php?ID=36213]).
+
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.
  
: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:Amish|Amish]] ([[User talk:Amish|talk]]) 16:36, 21 May 2017 (UTC)
  
== oml2 entries ==
+
: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.
 +
:
 +
:[[User:Amish|Amish]] ([[User talk:Amish|talk]]) 04:56, 16 August 2017 (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.
+
::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)
  
[[User:OlivierMehani|OlivierMehani]] ([[User talk:OlivierMehani|talk]]) 08:49, 15 August 2012 (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.
 +
:::[[User:Amish|Amish]] ([[User talk:Amish|talk]]) 09:55, 16 August 2017 (UTC)

Latest revision as of 16:30, 9 November 2017

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)