I checked more than half a century worth Unix experience and neither my colleagues, nor myself has ever set a password on a group (sg and gpasswd). What would be a typical use case for a group password or is it pretty much only there because of historic reasons?

  • 6
    Maybe I should send Ken an email, asking for his consideration during the design phase ;o)
    – jippie
    Oct 5, 2013 at 8:54

4 Answers 4


I too have never ever seen this feature used, not even one time. Most SA's aren't even aware that this facility exists. In looking at the man page for gpasswd there was this note:

Notes about group passwords

  Group passwords are an inherent security problem since more than one 
  person is permitted to know the password. However, groups are a useful 
  tool for permitting co-operation between different users.

Why they exist

I think they were a natural idea in mimicking the model of user's having passwords, that it made sense to duplicate that use case model to groups as well. But in practice they're really not all that useful for anything.

The idea with a group password is that if you needed to gain access to a particular group (one that you weren't listed as being a member of), you could do so using the newgrp command, and be challenged with a password to gain access to these alternative groups.

The big problem with them is that there is only a single password for each group, thus forcing people to share this single password, when multiple people required access to this one particular group.


Most environments I've come across have typically put people in secondary groups, and then given these groups access to files on the filesystem, and this has satisfied pretty much all the usage that needs to occur.


With the advent of sudo additional permissions could be handed out on an as needed basis to groups, further undermining any use cases that group passwords may have provided. If you needed to allow users more permissions, it was much easier to create roles in sudo and then just allow there username or group that they were in, permissions to elevate there permissions so that they could perform a particular task.


Finally the ability to create Access Control Lists (ACLs) really gave the last bit of flexibility that the User/Group/Other permissions model couldn't provide alone, relegating any possible need for group passwords to obscurity.

  • You already mention sudo and ACLs. I guess udev comes with a similar story, of course with a focus on devices. Interesting read.
    – jippie
    Oct 1, 2013 at 6:34

Here's a practical use for group passwords, that I implemented for myself on our work server, since the logs indicated my account was being brute-forced (or could have been a dictionary attack).
I used ssh-keygen and puttygen respectfully to generate key pairs for use from my workstation and home computer. The key I use from home requires a password. I added both of the public keys to the .ssh/authorized_keys, created a group marionette with a password and no members. As root I used visudo to add the following lines.

Cmnd_Alias      SUDOING = /bin/bash, /usr/bin/sudo -i
%marionette     ALL=NOPASSWD:SUDOING

I have disabled my account's password, you no one can log into it that way. I now login only with my keys and entering the password-protected group with newgrp marionette allows me to become root using sudo -i.
Without the NOPASSWD: option it will require your user account password. If it is disabled and this group does not have NOPASSWD, you will not be able to sudo -i. It will also require your user account password if your command list does not have /bin/bash or whatever shell your root is using by default.

While this does make the path to sudoing a few steps longer, it adds a good layer of security. If you choose to make all your accounts like this, create one local account with a password and sudo privileges, but deny it ssh entry from /etc/ssh/sshd_config by adding something like:

DenyUsers root caan
DenyGroups root daleks

This is necessary for local access in case you reinstall and forgot to backup your access keys.

  • you could do this much better without sudo if you instead used the POSIX newgrp command. still, excellent answer.
    – mikeserv
    Sep 4, 2014 at 16:39
  • 1
    Not exactly an answer to the question, but an excellent proposal for usage and combination of "old" (newgrp) and "new" (sudo) with a clear added value. This deserves some kudos.
    – Dirk
    Feb 28, 2019 at 11:00
  • 1
    Wouldn't it be better to add AuthenticationMethods publickey,password to /etc/ssh/sshd_config so that logging in from ssh requires both password and public key? (a tip from here
    – JiaHao Xu
    Feb 23, 2020 at 7:34
  • 1
    And isn't is more secure if you configure ssh 2fa according to here and there?
    – JiaHao Xu
    Feb 23, 2020 at 7:48
  • You're re-inventing the wheel (pun-intended) -- there is a better way. It's more secure to disable password authentication to sshd entirely. No need for user group either. You can still have a user password so that if someone does manage to get in (or you accidentally run a malicious script) they are still greeted with a password when they sudo. This password is now not shared with all the other privileged users since it uses your local user account's password. This also means users cannot accidentally set a weak password that is exposed to the internet. Mar 22, 2021 at 19:46

I have never seen a use-case for that password, too. And that is about 20 years of *nix experience.

The only use-case that comes to my mind is to set it to "!" - locked, so no one, not being a member of that group can change to it with the newgrp command.

If I look into /etc/group on SLES or /etc/gshadow on RedHat-based systems this seems to be the "typical" use-case. SLES did not even bother to create a shadow-mechanism for that password.

  • Not sure what you mean. Eg. I can't newgrp ntp already, how does !-locking change that?
    – jippie
    Oct 1, 2013 at 15:46
  • @jippie - so what is the password-field for ntp on your system? If it were some easy to guess password, your would be able to do newgrp ntp. With ! you are not able to.
    – Nils
    Oct 1, 2013 at 20:11
  • That is just an example, it has an 'x' and there are no group members other than ntp user itself. I just don't get what problem you are solving by setting the password field to !
    – jippie
    Oct 2, 2013 at 5:32
  • 2
    From man newgrp: The user will be denied access if the group password is empty and the user is not listed as a member.
    – user2387
    Oct 6, 2015 at 17:28

Let me suggest a use case.

First let me say that we are so used to the term "user" that we even don't think about it. But "user" is not really a user. For example, at home we have three computers - the laptop of my wife, my laptop and common desktop computer. When I use the laptop of my wife I login with her user account. When She use my laptop she logs in with my user account. If somebody needs the desktop he or she uses the one common account. We see here that the thing the computer system calls "user" is not really a user but a workflow - a set of activities.

Here is the question: Why can't I have more than one activity - one for every different job that I have? I can. At my work computer I've created (experimentally) many different users so I can focus on the current task. I put all these users in the same group so I can access my files no mater which user I am currently using.

So where does the gpasswd fits in this?

The default behavior of Ubuntu is to create a special group for every user.

What if we decide to think about these primary groups as users and to think about the system users as workflows?

Than these new users would need a password to login, right? Here is the place of gpasswd. I still need to figure out how to login with the group (up to this point what I know is that you can switch groups with gpasswd if you are already logged in).

  • the group password is the whole point of this question, though, which you haven't addressed.
    – Jeff Schaller
    May 23, 2017 at 16:09
  • From a security and accountability point of view, which is very common in IT, using someone else's user account is unacceptable. Although it may work for your home situation, it is bad practice for corporate environments.
    – jippie
    Jun 9, 2017 at 20:50

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.