Reload a Linux user's group assignments without logging out

Question

When assigning a user's secondary group list using:

# usermod -G <grouplist> <user>

is it possible to force this group assignment to take effect without logging out all running sessions?

This would be very useful in the situation where a Screen session exists with many running shells, as the entire session essentially needs to be destroyed to make the group assignment take effect.

I think I can change the user's primary group in a running shell using the newgrp command - is there some alternative that would work for secondary groups?

Ideally, I'd want something that would take effect in each shell without being run manually in every one, but failing that, maybe some way of forcing Screen to execute the same command in each.

Answer 1

Horribly hacky, but you could use two layers of newgrp to achieve this for a particular group:

id -g

...will give you the current primary group ID. We'll call this orig_group for the purposes of this example. Then:

newgrp <new group name>

...will switch you to that group as the primary and add it to the list of groups returned by groups or id -G. Now, a further:

newgrp <orig_group>

...will get you a shell in which you can see the new group and the primary is the original one.

This is horrible and will only get you one group added at a time, but it has helped me out a couple of times to get groups added without logging out/in my whole X session (e.g. to get fuse added as a group to a user so that sshfs will work).

Edit : This doesn't require you to type your password either, which su will.

Answer 2

From inside a shell, you can issue the following command

su - $USER

id will now list the new group:

id

Answer 3

This nifty trick from this link works great!

exec su -l $USER

I figured I'd post it here as every time I forget how to do this, this is the first link that come up in google.

Answer 4

1. Getting a shell with the new group without logging out and in again

If you're only adding one group, I used the following:

exec sg <new group name> newgrp `id -gn`

This is a variation on Legooolas's two-layer newgrp trick, but it is in one line and doesn't require you to manually enter your primary group.

sg is newgrp but accepting a command to execute with the new group ID. The exec means that the new shell replaces the existing shell, so you don't need to "logout" twice.

Unlike using su, you don't need to type in your password. It also doesn't refresh your environment (other than adding the group), so you retain your current working directory etc.

2. Executing the command in all Screen windows in a session

The at command in Screen runs a command in whatever windows you specify (note this is a Screen command, not a shell command).

You can use the following command to send the command to all an existing Screen sessions:

screen -S <session_name> -X at \# stuff "exec sg <new_group_name> newgrp \`id -gn\`^M"

Note the need to escape the backticks to get id to run in the Screen session, and the ^M to get Screen to hit 'enter' at the end of your command.

Note also that screen's stuff command simply types the command text on your behalf. Therefore something strange may happen if one of the screen windows has a half-written command at a command prompt or is running an application other than a shell (e.g. emacs, top). If this is an issue, I have some ideas:

• To get rid of any half-written command, you can add "^C" to the start of the command.
• To avoid running the command in an emacs window, etc, you could ask `at' to filter on window title etc (in the example above, I use "#", which matches all windows, but you can filter by window title, user, etc).

To run the command in a specific window (identified by window number), use the following:

screen -S <session_name> -p 0 -X stuff "exec sg <new_group_name> newgrp \`id -gn\`^M"

Answer 5

Using newgrp command solved problem for me:

newgrp <GroupName>

This blog post has detailed explanation.

Answer 6

You can do this.

Add as many groups as you want using usermod -G. Then, as the user with a running session, run newgrp - with just the '-' argument.

This reinitializes the group id to the default, but it will also set the secondary groups as well. You can verify this by running groups from the current session, before and after the usermod and the newgrp.

This has to be run from each open session - I don't know much about screen. However, if it's possible to iterate over all open sessions and run newgrp, you should be good. You won't have to worry about knowing the groups or the group IDs.

Best of luck to you.

Answer 7

Groups are usually enumerated at login, there is no way I know of to force it to re-do group enumeration without logging out and back in again.

Many answers voted up here seem to use a workaround that invokes a new shell with fresh environment (same as logging in again). the parent shell and all other continuously running programs will generally not receive the new group membership until being re-invoked from a fresh shell usually after clean logout and login.

Answer 8

To summarize:

exec newgrp <newlyaddedgroupname1>
exec newgrp <newlyaddedgroupname2>
...
exec newgrp -

Using 'exec' means replace the existing shell with the new shell started by the newgrp command (so exiting from the new shell logs you out).

The final newgrp - is needed to restore your normal primary group, so files you later create will have that as their group owner.

Note: The original poster's question was how to make newly-added groups visible in existing processes. The gpasswd and usermod commands don't affect existing processes; newly-added (or deleted!) groups appear in (disappear from) your account, i.e. in the /etc/group and /etc/gshadow files, but permissions for existing processes aren't changed. To remove permissions you have to kill any running processes; newgrp - will not re-read /etc/group and reset the group list; instead, it seems to just use the groups previously associated with the process.

Answer 9

I couldn't get the newgrp command to work. I'm not sure if this depends on /etc/sudoers, but I normally have to type my password for sudo, and this worked without requiring my password:

[leo60228@leonix:~]$ groups
users wheel

[leo60228@leonix:~]$ sudo echo hi
[sudo] password for leo60228:
hi

[leo60228@leonix:~]$ sudo -k # reset sudo timeout

[leo60228@leonix:~]$ exec sudo -i -u $(whoami) # no password necessary

[leo60228@leonix:~]$ groups
users wheel docker

Answer 10

I needed to do this in a shell script (script adds current user to a group, runs later commands that require that group membership). The newgrp command is brittle in that it can only run a new shell rather than an arbitrary command (I want to re-run the current shell script with original commandline args).

Here's my solution, which uses lots of bash-isms: (note the surrounding script needs some sort of branch to only run this function if the required group is not currently active):

(note: the script implies that it ran sudo adduser $user docker, which means it could also just run sudo docker everywhere instead of docker but that was undesirable in this case)

# save these for later
ORIGINAL_ARGS=("$@")

# This function is a little insane. The problem is this: user running
# this script is not a member of docker group, but used 'sudo' to add
# themselves to group. Without logging out and back in, the only way
# to gain access to that group is via the 'newgrp' command, which
# unfortunately starts a new shell rather than an arbitrary command...
#
# Also, we're going to newgrp twice: first to add the new group and
# again to restore the original group (but the new group remains in
# the 'groups' output).
#
# So this horrendous hack dups stdin to fd3 for later. Then runs
# 'newgrp' piping in a script that runs 'newgrp' a second time, piping
# in another script that restores stdin from fd3 and execs the
# original command...
restart-newgrp-newgrp() {
  # dup original stdin to fd3
  exec 3<&0

  local group="$1"
  local command="$0"
  local arg
  for arg in "${ORIGINAL_ARGS[@]}"; do
    printf -v command "%s %q" "$command" "$arg"
  done

  # restore original stdin from fd3; also replace any single-quote in
  # command with '"'"' to embed it in a single-quoted string
  local script
  printf -v script "exec newgrp %q <<<'exec <&3-; exec %s'" "$(id -gn)" "${command//\'/\'\"\'\"\'}"

  exec newgrp "$group" <<<"$script"
}

Answer 11

This does the trick if you have sudo and it can save you from entering your password one more time in some cases:

sudo su $USER

Answer 12

I had similar issue but also for not logged-in users. Restart of nscd didn't help, but executing this command did: nscd -i group. That should instruct nscd (caching daemon) to reload the groups file.