Talk:Users and groups

From ArchWiki
Latest comment: 11 September by Erus Iluvatar in topic Don't suggest /etc/sudoers, suggest a .d drop-in

Group list

It is a good idea to add a column with the default gid to every group in the wiki table ? e.g. what is group 102 ?

# ls -la  /usr/share/polkit-1
# drwxr-x--- 1 root  102  44 Dec 22 02:14 rules.d

Also I found in my cups directory files owned by 9xx. My first idea was to look in the wiki article...

Ua4000 (talk) 09:03, 24 December 2017 (UTC)Reply

You can find those in DeveloperWiki:UID / GID Database. Also note that there were recently some changes towards dynamic allocation of the IDs [1], so the table may not be entirely correct. -- Lahwaacz (talk) 09:09, 24 December 2017 (UTC)Reply

useradd primary / secondary group

I am noticing that the group created (with gid=uid) is empty by default in /etc/groups, is that expected or is it safer to also add manually the user in the group? Kewl (talk) 07:20, 20 May 2018 (UTC)Reply

The primary group is set in /etc/passwd, so it's fine that it appears empty in /etc/groups. Run groups to see all current groups. -- Lahwaacz (talk) 07:29, 20 May 2018 (UTC)Reply

Utilities to handle the shadow file in acrh

Referring the template:accuracy in the users and groups#Other tools related to these databases section: chage is just an example how one can modify the shadow file in arch. There are other utilties to modify other aspects of the shadow file. The versions of vipw and vigr in arch has far less options compared to Debian, for example. On arch, vipw -s exits with an error code of 1. Also compare vipw(8) to debian's man page. At the bottom of the later there is a reference to shadow-utils, as well as a link to passwd 1:4.5-1.1. shadow-utils is also mentioned for other distributions. Which is confusing. Can it be that shadow-utils has cease to exist at the upstream level, but continues to exist at the distributions level? Regid (talk) 17:01, 28 January 2019 (UTC)Reply

I'm not even sure how to parse any of this *or* the disputed section.
shadow is the only thing there is to discuss at all -- the upstream "shadow" project is mildly schizophrenic in that it calls itself "shadow" everywhere *except* the manpages which mention "shadow-utils". Debian packages the source package "shadow" as the split binary packages "login", passwd", and "uidmap" and does not package a binary package for either "shadow" or "shadow-utils" or anything else of the sort, while Fedora packages it as "shadow-utils". Arch Linux, Void Linux, Gentoo, OpenSUSE, Slackware, Solus, all have the "shadow" package.
The bug report plainly states that vigr, vipw specifically from util-linux are considered deprecated in favor acquiring those programs from the shadow project instead. (Then it was rejected in favor of un-deprecating the util-linux versions due to the shadow project not being responsible developers.) -- Eschwartz (talk) 21:25, 3 February 2019 (UTC)Reply
See this link for detail. chage,vigr and vipw them self are not deprecated. -- Fengchao (talk) 02:26, 2 April 2020 (UTC)Reply

Clarification in shared data info

In the second last paragraph in Example_adding_a_user, the wording can be improved a little perhaps. I had to reread it many times in order to understand what it meant. I could also suggest edits if required.

  1. May be an example group name like sdata can be used.
  2. Also mention about Access_Control_Lists as it is also a neat little way to give shared access to folders among multiple users or creating shared partition across multiple distros.

Let me know if I was being unclear with something due to my own bad english :p -- RaZorr (talk) 10:33, 24 December 2021 (UTC)Reply

Renaming a user/group

I renamed user and group XXX to YYY with usermod and groupmod and there is still a subuid and subgid. First time I hear about such a thing. We should maybe instruct how to rename these.

# grep XXX /etc -r
/etc/subgid:XXX:100000:65536
/etc/subuid:XXX:100000:65536

—This unsigned comment is by Aleb (talk) 21:17, 2 August 2024 (UTC). Please sign your posts with ~~~~!Reply

Don't suggest /etc/sudoers, suggest a .d drop-in

Currently the page suggest to edit /etc/sudoers which is bad practice as it is not manageable and will create needless pacnews.

The proper way of doing things is to create a /etc/sudoers.d drop-in, visudo can be used for this with the --file parameter too. C0rn3j (talk) 12:54, 11 September 2024 (UTC)Reply

We also need to update Sudo#Configuration to match. Erus Iluvatar (talk) 13:37, 11 September 2024 (UTC)Reply