How to update user/group settings of a running process

groupprivilegesprocessusers

Suppose I change some user settings like its initial login group or add it to a new group. I now can do su user and work with these new settings. But all the previously running processes will still have the same permissions as before.

How can I force a specific running process to re-read /etc/passwd and /etc/group to reinitialize its user and group settings, without terminating any activity it was doing? I've tried attaching to the process with gdb and do print setuid(MY_USER_ID), but despite the result was 0 (i.e. success), the process still remained with the same data (checked on bash running groups to see whether additional group has appeared).

Best Answer

Very interesting attempt. Actually, process's supplementary groups (defined in /etc/group) are set by setgroups system call. It requires CAP_SETGID privilege or being root.

So you can do like this:

# id
uid=0(root) gid=0(root) groups=0(root)

# gdb -q id
Reading symbols from id...(no debugging symbols found)...done.
(gdb) b getgroups
Breakpoint 1 at 0x401990
(gdb) run
Starting program: /usr/bin/id 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, getgroups () at ../sysdeps/unix/syscall-template.S:81
81  ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) call setgroups(5, {1, 2, 3, 4, 5})
$1 = 0
(gdb) d 1
(gdb) c
Continuing.
uid=0(root) gid=0(root) groups=0(root),1(daemon),2(bin),3(sys),4(adm),5(tty)
[Inferior 1 (process 8059) exited normally]
(gdb)

Per-user groups

I too don't see a lot of utility in per-user groups. The main use case is if a user wanted to allow "friends" access to their files, they can have the friend user added to their group. Few systems I've encountered actually use it this way.

When USERGROUPS_ENAB in /etc/login.defs is set to "no", useradd adds all the created users to the group defined in /etc/default/useradd by the GROUP field. On most of distributions, this is set to the GID 100 which usually corresponds to the users group. This does allow you to have a more generic management of users. Then, if you need finer control, you can manually add these groups and add users to them that makes sense.

Default created groups

Most of them came about from historic reasons, but many still have valid uses today :

disk is the group that owns most disk drive devices
lp owns parallel port (and sometimes is configured for admin rights on cups)
uucp often owns serial ports (including USB serial ports)
cdrom is required for mounting privileges on a cd drive
Some systems use wheel for sudo rights; some not
etc.

Other groups are used by background scripts. For example, man generates temp files and such when it's run; its process uses the man group for some of those files and generally cleans up after itself.

According to the Linux Standard Base Core Specification though, only 3 users that are root, bin and daemon are absolutely mandatory. The rationale behind the other groups is :

The purpose of specifying optional users and groups is to reduce the potential for name conflicts between applications and distributions.

So it looks as it is better to keep these groups in place. It's theorically possible to remove them without breakage, although for some, "mysterious" things may start to not work right (eg, some man pages not rendering if you kill that group, etc). It doesn't do any harm to leave them there, and it's generally assumed that all Linux systems will have them.

Adding a system user to an LDAP group with SSSD

This was enabled in sssd 1.9.5, by setting sssd.conf to include:

ldap_rfc2307_fallback_to_local_users = true

https://fedorahosted.org/sssd/wiki/Releases/Notes-1.9.5

Best Answer

Related Solutions

Reasons behind the default groups and users on Linux

Per-user groups

Default created groups

Adding a system user to an LDAP group with SSSD

Related Question