There is a proprietary document about system hardening/security standard stating that group users, nogroup, other, and some other groups should not contain any user except system administrators. I've found an explanation about nogroup group [here](https://unix.stackexchange.com/questions/22520/what-is-nogroup-groups-purpose) . What about the users and other groups and what are they for? Why regular (non-administrator) users should not be member of these groups? Distro is, RHEL (Red Hat Enterprise Linux)

I did not save the syntax to post here but I got a warning popup mentioning something about using the users group, which is gid 100, with the **insinuation** that I should not be using it. I think it may have been around the context of a RHEL 8/9 system which was using LDAP as the back end to manage user accounts on the system instead of /etc/passwd... but I am not sure. What is the current convention & best practice of making use of gid = 100 users group as it comes pre-defined in RHEL 8 and RHEL 9, and presumably still in RHEL 10 ? Is there a reason when not to use it?

I'm trying to create a decent user/group permission structure for my docker containers but perhaps i don't understand groups and docker access as well as i should The actual use case is I am running multiple docker containers through a single docker compose file and each has some access into a few or more of the drives and I'm trying to sort that access out into what permissions each should have correctly, its a physical pc running ubuntu server 24.04 I've got it to the point where the users and groups work fine on the host OS so i can write and read when using sudo su user1, user2 and so on, I'll just focus on one account and container for the rest of the post once that's working i can replicate for the others The drives have their own groups, there is an individual users for each docker container, each one contains the drive groups it needs the permissions are now 775 for directories and 664 for files within every drive All drives exist in /mnt/ on the host ls /mnt -al total 52 drwxrwxr-- 7 admin alldrives 4096 Jun 26 07:15 . drwxr-xr-x 23 root root 4096 Jun 29 01:12 .. drwxrwxr-x 3 admin drivea 4096 Jul 1 04:18 drivea drwxrwxr-x 1 admin driveb 64 Jun 12 2021 driveb drwxrwxr-x 1 admin drivec 34 May 19 2021 drivec drwxrwxr-x 16 admin drived 4096 Apr 21 00:54 drived They are mounted in fstab UUID=auuid /mnt/drivea auto defaults 0 0 UUID=auuid /mnt/driveb btrfs defaults 0 0 UUID=auuid /mnt/drivec btrfs defaults 0 0 UUID=auuid /mnt/drived auto defaults 0 0 Some are btrfs others are just ext4 single drives There is a group containing all drives - alldrives The reason for that is I identified that the root root default /mnt ownership was blocking access earlier, changing that to admin alldrives allowed the accounts to then see the files However in the docker containers they don't work they can view but not write, I think this is because the user/group mapping is not translating correctly between host os and docker container If i change the chmod access to 777 then it works from within the containers so i assume this means the account in the container isn't correctly linking to the group or user outside? The accounts intended to be used for the docker containers are like so id user1 uid=1006(user1) gid=1008(user1) groups=1008(user1),1002(driveb),1005(drivea),1007(alldrives) the main os user account is id admin uid=1000(admin) gid=1000(admin) groups=1000(admin),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),101(lxd),1001(docker),1007(alldrives) All the docker containers use environment variables to set the PGID and PUID .env file has ServicePUID=1006 ServicePGID=1008 paths to drives DRIVEA=/mnt/drivea DRIVEB=/mnt/driveb DRIVEC=/mnt/drivec DRIVED=/mnt/drived TMP=/tmp/afolder The docker compose script has PUID, PGID set and I've tried setting a UMASK and a user with little success - PUID=${ServicePUID} # default user id, defined in .env - PGID=${ServicePGID} # default group id, defined in .env - TZ=${TZ} # timezone, defined in .env - UMASK=002 user: ${ServicePUID}:${ServicePGID} My understanding of this is if i don't set the user property the container runs as root id 0 which allows it to read and write in the folders, if i connect to it over bash. The actual runtime of the service within the container however still uses the supplied puid and pgid which has the same permission issues, it just means its harder to verify since it looks like its working when you connect to troubleshoot. The volumes for the container are defined as volumes: - /etc/localtime:/etc/localtime:ro - ${DRIVEA}:/data - ${DRIVEB}:/config - ${TMP}:/tmp if i sudo in as that user on the host OS sudo su user1 I can run ls on the relevant drives ls /mnt/drivea/ -al drwxrwxr-x 15 admin drivea 4096 Jun 29 03:53 . drwxrwxr-x 3 admin drivea 4096 Jun 30 11:24 .. drwxrwxr-x 2 admin drivea 4096 Mar 29 23:31 afolder And create files touch /mnt/drivea/afolder/testfile $ ls /mnt/drivea/afolder/ -al drwxrwxr-x 15 admin drivea 4096 Jul 1 03:54 . drwxrwxr-x 3 admin drivea 4096 Jun 30 11:24 .. -rw-rw-r-- 1 user1 user1 0 Jul 1 03:54 testfile The files are created with the correct user and group with the correct permissions 664 So from the OS level i think I'm ok? The docker compose script is run using the admin account, I'm not sure if that has a bearing on this but the admin account has membership for alldrives and is the owner of them when i connect to the container to test these permissions sudo docker exec -t -i service /bin/bash id uid=1006 gid=1008 groups=1008 ls /data/afolder -al total 128 drwxrwxr-x 15 1000 1005 4096 Jul 1 13:54 . drwxr-xr-x 4 root root 4096 Jul 1 09:37 .. -rw-rw-r-- 1 1006 1008 0 Jul 1 13:54 testfile touch /data/afolder/aaafile touch: cannot touch '/data/afolder/aaafile': Permission denied whoami: cannot find name for user ID 1006 Does anyone know where I've missed a step please? I did go down the ACL route briefly but then backed out of it as it seemed easier and accomplishable through just group memberships and it didn't work either at least at the point i was at then The docker container looks like its running as the correct user but that it cant map back out to the user outside of the container I've looked up and tried many fixes which could be causing issues I've changed the names of alot of this to generic sounding account names and groups, hopefully i haven't introduced any typos or red herrings Could this be because the user in the host os has these group memberships groups=1008(user1),1002(driveb),1005(drivea),1007(alldrives) But in the docker container they only have the one? groups=1008

On *Centos 6.5* (and probably any) linux, I can create a group: sudo groupadd mygroup and add several users to it: sudo usermod -a -G mygroup userA sudo usermod -a -G mygroup userB sudo usermod -a -G mygroup userC The number of users in my particular case is 20. How can I use a one-liner like: sudo usermod -a -G mygroup userA userB userC Even using for loop would be fine, but I'm not a bash specialist, so wondering.

I am trying to add user e.g. amit to group amit,as below. root# groupadd -g 1500 -f amit root# useradd amit -m -G sudo -u 1500 -g 1500 -o -p "amit" However, when I try to switch to user amit it gives out the message as below: root# sudo su - amit sudo: Account or password is expired, reset your password and try again Changing password for root. May I please know, why am I getting this message, what should I do in order to avoid getting this message and get directly switched to amit user.

I'm installing some of my data from my old server to my new server. Since I had my old server for ages, I have a huge amount of legacy data with, most certainly, legacy user and group names. When extracting, tar does its best to match the user and group info by name and uses the identifiers as a fallback or the current user as a last resort. What I'd like to do is make sure that all the users and groups exist before I do the extraction. That way all the files get the correct ids. To do that, the best way I can think of is to list all the user and group names found in the tar file. I know I can use the tar tvf backup.tar command to list all the files, but then I'd have to come up with a way to extract the right two names. I'm wondering whether there would be a simpler way than using the tv option. Some tool or command line options that only extracts the user name and group name, then I can use sort -u to reduce the list to unique entries. Anyone knows of such a feature? --- **Update:** For those interested in fixing the ownership after extraction (or in my latest case, after re-installing the OS, so no tar involved), I created a tool to do that safely on an entire tree: https://github.com/AlexisWilke/alex-tools/blob/main/tools/fix-ownership.cpp

Recently, one of my servers running Deb 10 stopped responding to everything except SSH. After solving an issue where the filesystem was read-only due to a botched fstab, I am now met with almost all services failing to load, which I've begun to work on one at a time. This is mariadb's failure, which during my Googling, seems to have something to do with systemd and group creds. I don't know where to go from here to find out why these errors are occurring. Could someone tell me what my first step would be in solving this issue? Dec    8 09:03:39 adolf systemd: mariadb.service: Failed to determine group credentials: No such process Dec    8 09:03:39 adolf systemd: mariadb.service: Failed at step GROUP spawning /usr/bin/install: No such process Dec    8 09:03:39 adolf systemd: mariadb.service: Control process exited, code=exited, status=216/GROUP Dec    8 09:03:39 adolf systemd: mariadb.service: Failed with result 'exit-code'. Dec    8 09:03:39 adolf systemd: Failed to start MariaDB 10.3.22 database server. Thanks for the help!

Upon the launch of VirtualBox (exact version 7.0.10-158379~Ubuntu~jammy) on my Linux Mint 21.3, I am _greeted_ with a message in the upper-right corner: > Can't enumerate USB devices and if I try to connect a USB device in the VM settings I get: > No devices available *** I know there should be and there is vboxusers user group, but it appears to have no members:

$ grep vboxusers /etc/group
vboxusers:x:129:

The following links discuss these concepts in different contexts. I have read their definitions, but I still can't tell how they are related, or if some of them are just the same. * Current group ID * Group ID * Primary and supplementary group IDs * Effective and real group IDs (also on Wikipedia ) ### Here is one example of the source of my confusion: According to man id , if I type id, I should get what they call **effective** and **real** group IDs. id uid=501(joe) gid=501(joe) groups=501(joe), 100(users) However, Wikipedia refers to the output of id to distinguish between **primary** and **supplementary** IDs. Moreover, Wikipedia distinguishes between **primary** vs **supplementary** and **effective** vs **real** group ids. How do these concepts relate to each other? Also, is it true that **primary** group ID = **group ID** = **current** group ID?

I migrated from Ubuntu-20 to Debian-12, and I can't excute the command sudo with my username my_name within a fresh installed system. So, I added my_name into "sudo" group(usermod -aG sudo my_name) within a root logged-in terminal, and then rebooted my computer. But it doesn't work, I still get the message like "my_name is not in sudoers file...". I found a strange thing, i.e. when I issue groups command within a terminal window that logged-in as my_name, the "sudo" group name do **NOT** exist in the group list. But when I execute groups my_name with root's permission, the "sudo" group name **DO EXIST** in the group list! Is this a bug of Debian-12? Or I missed some action?

In /etc/group there is a group users with numerical group ID 100. When I install RHEL 7,8, or 9 it **does not** allow me to create the initial user with a primary group ID of 100. The GUI always snaps back to 1000 which creates a new group having the username as a new group name. I do not like that. Why does the RHEL installer (and presumably any other currently), not allow you to set that user's primary GID at install time to gid=100? I have the assumption it is ok to have some ~50+ local users on the system defined in /etc/passwd all having a gid of 100 users. Is there any downside to this? What is the convention and history of gid 100 *users* ? Does users having a low gid (100) versus 1000 and above pose any kind of problem?

I just added myself to "docker" group on my workstation. I dutifully logged out and in again on my desktop environment but I'm still not on the group: mcon@cinderella:~$ id uid=1000(mcon) gid=1000(mcon) groups=1000(mcon),20(dialout),27(sudo),46(plugdev),115(lpadmin),124(vboxusers) mcon@cinderella:~$ grep mcon /etc/group dialout:x:20:mcon,mauro sudo:x:27:mcon plugdev:x:46:mcon mcon:x:1000: lpadmin:x:115:mcon vboxusers:x:124:mauro,mcon docker:x:136:mcon I'm under an up-to-date Debian Sid. My desktop is Gnome/Cinnamon I *know* this can be fixed by rebooting, but I would like to understand what's going on. Note that using the "su trick" actually works: mcon@cinderella:~$ su - mcon Password: mcon@cinderella:~$ id uid=1000(mcon) gid=1000(mcon) groups=1000(mcon),20(dialout),27(sudo),46(plugdev),115(lpadmin),124(vboxusers),136(docker) WHY logging out and then in again does not? *UPDATE*: further investigation shows that *after logout* there still are a ton of processes running with my userid, including systemd, sh, various gvfs-whatever, gpg-agent, etc. Killing the shell did not change anything and but I'm a bit scared about killing them all. Logging-out shouldn't end all activities in my behalf? This looks like a security hole (or not?). I will try to kill all those processes to see if something is "keeping session alive" (at worst I'll have to reboot). *Update2 (as asked by @StephenKitt)*: mcon@cinderella:~$ loginctl show-user $(whoami) UID=1000 GID=1000 Name=mcon Timestamp=Sat 2019-03-23 15:01:35 CET TimestampMonotonic=24931331 RuntimePath=/run/user/1000 Service=user@1000.service Slice=user-1000.slice Display=2 State=active Sessions=2 IdleHint=no IdleSinceHint=1553356954121832 IdleSinceHintMonotonic=7284187020 Linger=no *Update3 (inspired by @StephenKitt)*: Apparently session2 exists, but seems to be the only one present... but the command without argument gives a different view and says there's only one active session. I'm quite confused; where does the "Sessions=2" above come from? mcon@cinderella:/tmp/ca$ loginctl show-session EnableWallMessages=no NAutoVTs=6 KillUserProcesses=no RebootToFirmwareSetup=no IdleHint=no IdleSinceHint=1553356954121832 IdleSinceHintMonotonic=7284187020 BlockInhibited=handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch DelayInhibited=shutdown:sleep InhibitDelayMaxUSec=30s UserStopDelayUSec=10s HandlePowerKey=poweroff HandleSuspendKey=suspend HandleHibernateKey=hibernate HandleLidSwitch=suspend HandleLidSwitchDocked=ignore HoldoffTimeoutUSec=30s IdleAction=ignore IdleActionUSec=30min PreparingForShutdown=no PreparingForSleep=no Docked=yes LidClosed=no OnExternalPower=yes RemoveIPC=yes RuntimeDirectorySize=3314405376 InhibitorsMax=8192 NCurrentInhibitors=7 SessionsMax=8192 NCurrentSessions=1 mcon@cinderella:/tmp/ca$ loginctl show-session 2 Id=2 User=1000 Name=mcon Timestamp=Sat 2019-03-23 15:01:35 CET TimestampMonotonic=24933340 VTNr=7 Seat=seat0 Display=:0 Remote=no Service=lightdm Desktop=lightdm-xsession Scope=session-2.scope Leader=2009 Audit=2 Type=x11 Class=user Active=yes State=active IdleHint=no IdleSinceHint=1553356954121832 IdleSinceHintMonotonic=7284187020 LockedHint=no

I'm on Ubuntu 24. Originally, the system had an existing group with gid 999:

# cat /etc/group | grep 999
systemd-journal:x:999:

(I mistakenly tried to create a group with that duplicate ID: groupadd docker -g 999) - UPDATE: I originally thought I was responsible for creating the duplicate group ID, but after a bunch of troubleshooting, it seems that it was created by the LDAP server. So the prior statement is not correct. Now I'm stuck unable to add users to the group (properly) and unable to delete the docker group in order to start over. Firstly, there's no docker group in /etc/group:

# sudo cat /etc/group | grep docker

If I run getent group docker, then I get the users who are in the original group with gid 999 - those that belong to the systemd-journal group:

# getent group docker
docker:*:999:ausername,anotherusername,yetanotherusername

I can't change its gid:

# sudo groupmod -g 899 docker
groupmod: group 'docker' does not exist in /etc/group

I can't delete the docker group either:

# sudo groupdel docker
groupdel: cannot remove entry 'docker' from /etc/group

I'm also not allowed to create the docker group again:

# sudo groupadd -g 899 docker
groupadd: group 'docker' already exists

If I try to change the group of a file to be the docker, it'll actually assign the original group (systemd-journal) that gid 999 belongs to:

# sudo chown root:docker /tmp/foo
# ls -l /tmp/foo
-rw-r--r-- 1 root systemd-journal 0 Jan 25 03:50 /tmp/foo

The contents of /etc/nsswitch.conf are:

passwd:         files systemd sss
group:          files systemd sss
shadow:         files systemd sss
gshadow:        files systemd

hosts:          files dns
networks:       files

protocols:      db files
services:       db files sss
ethers:         db files
rpc:            db files

netgroup:       nis sss
sudoers: files  sss
automount:  sss

How can I reset things so that I can re-create (or change the gid of) the docker group?

I've been reading up on the "sticky bit" and it's _almost_ what i want… but not quite. ## Background I'm managing a small JupyterHub instance with three courses and an instructor for each course. I'd like to have a folder on the server for file submissions. Students (in the jupyterhub-users group) should be able to place their own files in the folder, but should not be able to move or view other files in the folder. Ideally, they should retain the ability to move or edit their own file. Course instructors (in the jupyterhub-instructors group) should have full access to files and folders in the submissions folder so they can move their students submissions around as they see fit. ## My current understanding I'm aware of the sticky bit… my problem with it is that it leaves the other instructors unable to modify the contents of the folder. Is there a version of the sticky bit that allows the _group_ to edit the folder? In that case, I can set ACLs such that jupyterhub-users have rwx permissions on the folder (allowing them to submit files to the folder and see the contents of it) and set the folder owner to root:jupyterhub-instructors so the instructors can control the contents of the folder. If all else fails, I suppose I can make subfolders in the submissions folder owned by each instructor, then set the sticky bit on each subfolder. I'd like to avoid the future maintenance associate with that though, since _I'll_ have to be the one to remember to set up a new folder next semester for each instructor.

I have a situation where one user (minknow) is creating files/directories and I want another user (mine, nano2) to have rwx (full) access to them without having to sudo change permissions every time a new directory is created. So I have attempted to solve this problem by simply adding the primary group of the minknow user as a secondary group to the nano2 user using the command below:

-sh
sudo usermod -a -G minknow nano2

This should add the group minknow to the user nano2. I have then checked the groups by using the id -Gn command to verify the addition of the group:

-shellsession
nano2@nano2:/var/lib/minknow/data/P2_WGS_v3/23RKG025670$ id -Gn nano2
nano2 adm cdrom sudo dip plugdev lpadmin sambashare minknow docker

But it does not work as intended. The nano2 user does not have permissions as part of the minknow group - I have a directory created by the minknow user with the following permissions (lloutput):

drwxrwxr-x  3 minknow minknow 4096 Jan  8 10:46 23RKG025670/

The nano2 user is unable to create any files within that directory. Now, I happened to also check the id command without specifying the username. Per my understanding, this should simply output *my* ID and groups, but the output is slightly different from that above:

-shellsession
nano2@nano2:/var/lib/minknow/data/P2_WGS_v3/23RKG025670$ id -Gn
nano2 adm cdrom sudo dip plugdev lpadmin lxd sambashare

Two groups are missing, including the minknow group. I have verified that my user is in fact nano2 with the whoamicommand. What is going on here? * What is the difference id and id {my_own_username}? * And why does my attempt at granting groups permissions to nano2 fail?

I have a Debian 10 machine which uses PAM LDAP for authentication. In LDAP I have two users alice and bob which are both members of group mygroup. Everything has worked fine (so the configuration shouldn't be too far off) until I recently discovered some weirdness with my groups (not sure what happened): - ldapsearch reports user alice as a member of group mygroup (as it should). - getent group shows user alice as a member of group mygroup (as it should).

root@tux:~# getent group | grep mygroup
    mygroup:*:1210:alice,bob

- id does _not_ report alice to be a member of group mygroup:

root@tux:~# id alice
    uid=1200(alice) gid=1200(alice) groups=1200(alice)

- Surprisingly enough user bob is reported to be a member of mygroup:

root@tux:~# id bob
    uid=1201(bob) gid=1201(bob) groups=1210(mygroup),1201(bob)

So far I thought that both getent and id are getting their information from the Name Service Switch library (NSS). I'm confused and hoping for some hints how to troubleshoot.

I have an Ubuntu server with ~6-7 users. We all use some software that requires some shared files and folders to be regularly updated. Let's call that shared directory /opt/science/online-data Within this are some calibration and data files that are updated on an irregular basis on an external public server not owned by me. I have a cron job that runs an rsync command every day at 5 AM to keep it up-to-date. In everday usage, this folder just needs to be readable by all users (not written to). However, there are times where the software throws an error indicating that the online-data folder needs to be immediately updated before the software can be used. I'm not always around as admin to run that command. I'd like to set things up so that any of my users can run a script "update_online_data.py" or whatever, and it will trigger the rsync. I tried doing this by having the online-data folder group set to a specific group "softwaregroup" and giving all users membership, but the users are reporting permission errors. That's probably an error I can figure out (I'm pretty sure this should work.), but I wonder if there is a more secure way to do this anyway? Right now the group membership could in theory allow them to mess up those files when I really do not want them to do anything other than the rsync. Is there a way to create a command that triggers a non-login user specific to this task to do this and only this? (I have a vague idea that daemons or services might be a possibility, but I don't have a lot of experience using them in a custom way.)

I checked more than half a century worth Unix experience and neither my colleagues, nor myself has ever set a password on a group (sg and gpasswd). What would be a typical use case for a group password or is it pretty much only there because of historic reasons?

I don't understand why newgrp prompts me for a password when I want to change my group.  I don't even know what password it is asking for, but it is certainly not mine (user clime). $ id uid=500(clime) gid=501(www) groups=501(www),500(clime) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $ newgrp clime Password: <--- huh?! My system is CentOS 6.3.

I've recently been creating new users and assigning them to certain groups. I was wondering if there is a command that shows all the users assigned to a certain group? I have tried using the 'groups' command however whenever I use this it says 'groups: not found'