Right, so you’ve set up your groups, you’ve got your file permissions humming along, and now you need to do something as a different group. sudo is the sledgehammer for switching users, but what if you just need to switch your group context? That’s where newgrp comes in. It’s like a temporary backstage pass that gives your process the permissions of another group, without all the hassle of a full login.

Think of it this way: when you log in, the system gives you a ticket with your primary group (the one listed in /etc/passwd) and a list of all your supplementary groups (from /etc/group). This ticket governs what files you can access. The newgrp command is you walking up to the bouncer, showing them you’re on another list (i.e., your username is in that target group), and getting a new, temporary ticket for the night. Crucially, this isn’t just changing a setting; it starts a whole new shell session as a child of your current shell. This is the most important thing to understand and the source of most confusion.

How It Actually Works (The Shell Within a Shell)

Let’s be absolutely clear about what happens because it’s weird and feels like magic. When you run newgrp, it’s an executable command that, upon success, launches a new shell instance. Your current shell waits for that new shell to exit. This is why your prompt might look slightly different afterward—you’re in a sub-shell. Your effective group ID (the one used for permission checks on new files you create) is changed for this new shell and all its children. When you type exit, you kill that sub-shell and pop back to your original shell with your original group context intact.

# Let's say my primary group is 'vaughn' and I'm also a member of 'developers'
$ id -gn
vaughn
$ id -Gn
vaughn developers sudo

# Now I want to create a file as the 'developers' group
$ newgrp developers
# You are now in a new shell. Notice the process tree:
$ pstree -p | grep $$
|-gnome-terminal-(1000)-+-bash(1010)---newgrp(1234)---bash(1235)

# In this new shell, my effective group is now 'developers'
$ id -gn
developers

# Any file I create now will be owned by my user and the 'developers' group
$ touch new_file.txt
$ ls -l new_file.txt
-rw-r--r-- 1 vaughn developers 0 May 21 10:00 new_file.txt

# When I'm done, I exit this sub-shell
$ exit
exit
# Now I'm back in my original shell (PID 1010)
$ id -gn
vaughn

The Password Shenanigans

Here’s where the designers made a… choice. What if you want to use newgrp with a group you are not a member of? The command doesn’t just tell you to get lost. Instead, it will prompt you for the group’s password. Yes, groups can have passwords. No, this is not a common or terribly secure practice in modern systems, but the capability is there, languishing in a corner like an old fire extinguisher with a faded inspection tag.

If you get the password right, newgrp will grant you access anyway, effectively making you a temporary member for the life of that shell session. This is a legacy mechanism for allowing temporary access to a resource. You’ll likely never set a group password, but it’s good to know why it’s asking.

$ newgrp accounting
Password: # (You enter the password for the 'accounting' group here)

Common Pitfalls and How to Avoid Them

  1. The Sub-Shell Trap: The biggest “gotcha” is forgetting you’re in a sub-shell. If you run a script that uses newgrp from within another script, it will spawn that shell and then… just sit there, waiting for input. It won’t continue your script. For scripting, you almost always want sg (which is similar but designed for single commands) or simply using sudo -g instead.

  2. Environment Confusion: The new shell started by newgrp is a login shell. This means it will re-read your .profile or .bash_profile and reset many environment variables. This can lead to unexpected behavior if your startup files have commands that alter your path or prompt. If your prompt suddenly changes, this is why.

  3. It’s About Effective Group, Not Supplementary Groups: newgrp changes your effective group ID. It does not add a new group to your list of supplementary groups. Your access is still based on your complete list of groups, but the permission checks for creating files and, critically, the group bit of the umask, will use this new effective group.

Best Practice: Just Use sg or sudo in Scripts

For any kind of automation, newgrp is the wrong tool. Reach for sg (which works like newgrp but for a single command) or the more versatile sudo. The sg command is literally in the newgrp man page and is what you should use.

# Using 'sg' to run a single command with a different group
$ sg developers "touch /path/to/project/file.txt"
# The file will be created with the 'developers' group
$ ls -l /path/to/project/file.txt
-rw-r--r-- 1 vaughn developers 0 May 21 10:05 file.txt

# Or, using sudo (if you have permissions)
$ sudo -g developers touch /path/to/project/file.txt

So, use newgrp for an interactive session where you need to do a bunch of work as a different group. It’s your quick-context-switch command. But for everything else, especially scripts, use the more predictable and script-friendly alternatives. It’s a useful tool, but you have to respect its slightly quirky, old-school nature.