34

I changed permissions of a file (chmod g+w testfile) and running ls -l testfile gives:

-rwxrwxr-x 1 user1 user1 0 2011-01-24 20:36 testfile

I then added a user to that group ("/etc/group" has user1:x:1000:user2 line), but am failing to edit that file as user2. Why is this so?

3

8 Answers 8

56

user2 needs to log out and back in. Group permissions work this way:

  • When you log in, your processes get to have group membership in your main group mentioned in /etc/passwd, plus all the groups where your user is mentioned in /etc/group. (More precisely, the pw_gid field in getpw(your_uid), plus all the groups of which your user is an explicit member. Beyond /etc/passwd and /etc/group, the information may come from other kinds of user databases such as NIS or LDAP.) The main group becomes the process's effective group ID and the other groups become its supplementary group IDs.
  • When a process performs an operation that requires membership in a certain group, such as accessing a file, that group must be either the effective group ID or one of the supplementary group IDs of the process.

As you can see, your change to the user's group membership only takes effect when the user logs in. For running processes, it's too late. So the user needs to log out and back in. If that's too much trouble, the user can log in to a separate session (e.g. on a different console, or with ssh localhost).

Under the hood, a process can only ever lose privileges (user IDs, group IDs, capabilities). The kernel starts the init process (the first process after boot) running as root, and every process is ultimately descended from that process¹. The login process (or sshd, or the part of your desktop manager that logs you in) is still running as root. Part of its job is to drop the root privileges and switch to the proper user and groups.

There's one single exception: executing a setuid or setgid program. That program receives additional permissions: it can choose to act under various subsets of the parent process's memberships plus the additional membership in the user or group that owns the setxid executable. In particular, a setuid root program has root permissions, hence can do everything²; this is how programs like su and sudo can do their job.

¹ There are occasionally processes that aren't derived from init (initrd, udev) but the principle is the same: start as root and lose privileges over time.
² Barring multilevel security frameworks such as SELinux.

3
  • 3
    Note that if you're using a desktop GUI, simply logging out and back in to a terminal window will not reset group membership. I had this problem and I need to log out of my GUI session also :þ
    – user394
    Jul 14, 2014 at 14:15
  • 3
    @user394 Logging out and back in does reset group membership. If you merely close a terminal window, you aren't logging out. Jul 14, 2014 at 14:23
  • Thank you! super useful. Thanks to this knowledge, I was able to get the right permissions without logging out just by reloading Finder (holt alt while right clicking on it in the Dock), then re-launching Terminal from Finder.
    – Chris
    Oct 12, 2021 at 0:21
13

You might need to have user2 log out and back in (or just try ssh'ing in to create a new login session). Check the output of id --groups to show the numeric group ids for a user.

7

sudo su $(whoami)

Essentially the same workaround as ssh localhost, but usable without having an ssh server installed.

So long as you have root . But if you've just added a new group & changed permissions, you likely do.

1
  • While this is a much less informationally complete answer than the accepted one, sometimes you want to know how to build a clock, and sometimes you just want to know what time it is. This answer helped me with a trick that can work until I next log out and back in. Thanks. Jul 17, 2017 at 0:23
3

USING newgrp TO EFFECT TEMPORARY SOLUTION IN NEW SHELL:

The newgrp command can be used. It enabled the user to temporarily (in a new shell) change their primary group to a specified value.

Add the user1 group to user2

sudo usermod -a -G user1 user2

As user2 call newgrp user1

user2% newgrp user1
user2% id
uid=1001(user2) gid=1000(user1) 
groups=1000(user1),...,1001(user2)

then user2's primary group will immediately be user1, and a file write will result as user1 being the group owner. However, the primary group specified in /etc/passwd is not changed.

As user2 call newgrp user1 again

user2% newgrp user2
user2% id
uid=1001(user2) gid=1001(user2) 
groups=1001(user2),...,1000(user1)

and user2's primary group will immediately be set back to user2, while user2 will still belong to group user1. This is the effect that was initially expected from sudo usermod -a -G user1 user2, but did not happen immediately. In this state a file write will result as user2 being the group owner.

  • Note: Each invocation of newgrp results in a new shell. In bash this results in incrementing the value of the environment variable SHLVL by 1. After exiting the shell created by newgrp the effects are reversed, with no side effects. For that reason there still might conceivably be use cases where logout/reboot or some other solution is required, so I leave my previous answer below, which worked when logout didn't work, and avoided having to reboot. However, in practice, I find that newgrp is sufficient to cover every use case I face.

"PERMANENT" SOLUTION without REBOOT WHEN LOGOUT DIDN'T WORK

I found that the selected answer's suggestion

user2 needs to log out and back in. ... The kernel starts the init process (the first process after boot) running as root, and every process is ultimately descended from that process [and so it needs to be killed by logging out]

didn't work in Ubuntu 20.04 from the "Logout" GUI option, and that after logging out and back in this 'init' process with an older start time was remaining

root           1  0.0  0.1 168096 11744 ?        Ss   12:45   0:02 /sbin/init

Killing that might solve it, but I didn't do that, instead I killed this user process which also had an older timestamp

craig       1790  0.0  0.0 169360  3784 ?        S    12:46   0:00 (sd-pam)

simply because of my weak understanding that "pam" is a module for authenticating users. It worked, and thereafter id showed self with the correct group permissions.

Failure of logout to solve problem might (or might not) be related to systemd. I think maybe so after reading this.

6
  • 1
    -1 for the second part - the fact that logout is broken on your system is totally unrelated to the original question. Oct 10, 2020 at 14:00
  • 2
    @JakubKlinkovský - However, it is not unrelated to the selected answer "user2 needs to log out and back in". Moreover, I don't believe it is just "my" system; I've seen multiple comments in other related questions (not just from those using 'ssh') complaining that logout doesn't update the added groups. Mine's the second day of a fresh install of 20.04 from install medium, not an update. I would say that it is very unlikely my installation is broken - and very likely that it is the actual behavior of all 20.04 correctly working desktop installs, of which there are probably several million. Oct 10, 2020 at 20:29
  • First, you should be answering questions, not other answers or comments. Second, so "your system" = Ubuntu 20.04. The original question is not related to Ubuntu at all. Oct 11, 2020 at 18:52
  • @JakubKlinkovský - The question is "... but am failing to edit that file as user2. Why is this so?". It IS answering that question - in certain very common situations the process (sd-pam) must be restarted after a logout, presumably because the authorizations that thread manages have not been updated. Oct 11, 2020 at 23:33
  • @JakubKlinkovský - I think you mean if an answer does not apply to all Unix & Linux systems equally correctly then it is an answer with negative value. In response I would note that the question is not limited to any particular distribution or release, and point out that the question also applies to ubuntu 20.04 (a member of the class Unix & Linux), and possibly applies to other distributions/releases using systemd, because (sd-pam) is systemd related process, as indicated by the obscure reference. An answer for a subset of of the class Unix & Linux is also valuable. Oct 11, 2020 at 23:41
2

There is a case when user logout does not help - if you are using ControlMaster ssh directive for the host. If you add your account to a group, logoff and logon again within the same ControlMaster connection, the session will still be showing you no new membership. You will have to forcibly break the Master connection with

ssh -O exit hostname

before loggin on again.

0

su seems to be enough in some cases, no need to sudo.
If there are any drawbacks, it would be interesting to know, please comment.

su --login $(whoami)

From man su:

su allows to run commands with a substitute user and group ID.

su [options] [-] [user [argument...]]

It is recommended to always use the --login option (instead of its shortcut -) to avoid side effects caused by mixing environments.

-, -l, --login Start the shell as a login shell with an environment similar to a real login:

  • clears all the environment variables except TERM and variables
    specified by --whitelist-environment
  • initializes the environment variables HOME, SHELL, USER, LOGNAME, and PATH
  • changes to the target user's home directory
  • sets argv[0] of the shell to '-' in order to make the shell a login shell
1
  • Answer inspired by @RGD2 answer. Just wondered why sudo would be needed.
    – ederag
    Feb 22, 2020 at 20:59
0

I can confirm, that under Ubuntu-MATE 20.04 x64 LTS nothing but reboot helps. Logout (truly, not switch user…) is not enough. All newgrp tricks are limited as expected to that one terminal.

What did work?

sudo loginctl terminate-user <user> 

Panels + Plank dissappear immediately. (Naturally, all your other stuff should be long saved and closed when you do this.) Background and your terminal shell stay around for another 10 seconds or so, a bit “stunned” and unresponsive (feels a bit like a killall mate-settings-daemon...), before you get kicked …err logged out.

Logging in again and you get the $> groups you always wanted... <3

Kudos to this solution on askubuntu.

Further plausible explanation in same thread. (tl;dr: some user-related task do not truly end upon logout but hang around... kill them while in the greeter, using a pure text session might be another option...)

0

You need to "reload" the groups of the current user. If you want to do it without having to start a new shell use the following command:

exec su -l $USER

exec replaces the current process image with a new process image, that is defined by the su -l $USER command, which is basically a new shell for the current user

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.