Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

share|improve this question

8 Answers 8

up vote 35 down vote accepted

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).

share|improve this answer
2  
Nice trick, I like it –  Simon Oct 10 '11 at 19:40
    
On Fedora I had to do newgrp $USER instead of newgrp <orig_group>. That means I didn't have to find my original primary group ID, so it's even easier than this solution. –  Richard Turner Jan 3 at 17:08

From inside a shell, you can issue the following command

su - username

where username, of course is your username. id will now list the new group:

id
share|improve this answer
    
I think this the best approach in many cases, but the original poster did want to update multiple shells within a screen session. This solution would have be be done from each shell. –  Adrian Ratnapala Dec 13 '11 at 8:57
1  
Nice trick, works great! –  genpfault Apr 3 '12 at 4:24
1  
The original solution would also only fix a single shell session in screen. I just tested that. The reason this solution works is because you are spawning a complete new session rather than inheriting from the original environment. –  Dror Feb 6 at 5:24

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.

share|improve this answer
1  
+1 for not putting the user in a subshell; you can logout/exit as usual with this. Also, if NOPASSWD: is set in /etc/sudoers, you can instead use exec sudo su -l $USER to avoid being prompted for password. –  Ivan X Aug 9 at 15:06

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.

share|improve this answer
    
Truthfully, I'm pretty sure that this isn't true - I'd found a way to do it before on a Linux box. However, for the life of me, I cannot remember what the command was. If I find it, I'll post it. Edit: Just found it, I'm posting it as an answer. –  lunchmeat317 Jan 30 '12 at 16:11

You can do this.

Add as many groups as you want using usermod -G. Then, as the user with a running session, run newgrp without any arguments.

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.

share|improve this answer
5  
tried on an xterm within an X session but it did not work –  dwery Jul 10 '12 at 19:27
    
tried in on a session in tmux and it did not work there either –  Michael Feb 12 '13 at 3:32

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
share|improve this answer

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.

share|improve this answer

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.

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

screen -S <session_name> -p 0 -X stuff "exec sg <new_group_name> newgrp \`id -gn\`$(printf \\r)"

Note the need to escape the backticks to get 'id' to run in the Screen session, and the $(printf \r) to get Screen to hit 'enter' at the end of your command.

The argument -p is the window name, or a number if they don't have names. Unfortunately I don't know of any way to enumerate the windows in a session or automatically execute the same command in every Screen existing session.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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