Quick Links
On Linux, files have three sets of permissions. One set is for the file's group. Before you allocate a file to a group, you may want to check who the group members are.
File and Directory Permissions
Files and directories on Linux have a set of permissions for the owner, another set for the group the file is allocated to, and permissions for everyone who isn't in one of the previous two categories.
Each set of permissions defines whether the members of that category can read, write, or execute the file. In the case of a directory, the execute action equates to being able to
cd
into the directory.
The default group for a file or directory is the default group of the owner. That's usually the person who created it. The group permissions are used to allow a collection of users to have controlled access to the files and directories of the other members of that group.
For example, you might have a team of developers, a documentation team, a research team, and so on. The members of each team can be added to a suitably named group, to aid collaboration. Users can be in many groups at once.
It's a simple but robust scheme. But if your files are sensitive, you may feel happier checking who the members of the group are, before you share your work with them. There are different ways to do this. But take note. The two most-frequently recommended methods are problematic.
The /etc/groups File
The "/etc/group" file contains a colon "
:
" delimited list of groups and group members. Each line has four fields.
- Name: The unique name of the group.
- Password: Not used. This will always hold "x."
- Group ID: The unique group identifier.
- Users: A comma-delimited list of the members of the group. The list is usually empty for system and daemon accounts.
To dump the contents of the file to the terminal window, you can use
cat
, but it's more convenient to be able to scroll through the contents of the file with less.
less /etc/group
Most of the entries at the top of the list have no members, although the "adm" group has two, and the "cdrom" group has one.
If we want to discover the groups a specific user is in, we can use grep to search for entries with their user account name. This isn't our task at hand. We want to see everyone who is a member of a group, not the groups that one person belongs to. But it is instructive for us to take a look.
grep "dave" /etc/group
The entries that contain the string "dave" are listed for us. And tucked away amongst them is a sign that things might not be as simple as we thought.
When a user is added to Linux, the default action is to place them in a group with the same name as their user account. This is their primary group. Any other groups they are added to are known as secondary groups.
The problem is that users are not listed as members of their primary groups. That's why the group "dave" is not showing any members, although the user "dave" is a member of that group.
Of course, system administrators can change the primary group of any user to that of any other group. That means a user can be a member of any group but they won't be listed as such in the "/etc/group" file. That's one issue.
The second issue is that the "/etc/group" file isn't a single source of truth. Modern Linux installations may well store user and group information in more places than "/etc/passwd" and "/etc/group", especially in corporate situations where services like Lightweight Directory Access Protocol are deployed. By only looking in one place, you might not be seeing the big picture.
In our test scenario, we created four groups for a development department. They are:
- resteam: The research team.
- devteam: The development team.
- pvqteam: The product verification and quality team.
- docteam: The documentation team.
We added people to these teams. Some people are in more than one team. If we open the "/etc/group" file in less and scroll to the bottom of the file, we'll see the new groups and group members. At least, as many members as the "/etc/group" file knows about.
If we want to extract a single group, we can search using grep. The caret "^" represents the start of a line.
grep "^devteam" /etc/group
This extracts the "devteam" entry from the file and lists all the group members. Or does it?
The getent Command
The getent command checks multiple databases for user group information, not just "/etc/group." We'll use getent to show us the user groups.
getent group
Using getent with the group option produces---on this test machine---the same results as using the "/etc/group" file. That's because we're not using LDAP or any other centralized naming service. So there are no other sources for getent to refer to.
It's no surprise then, that the results tally with those from the "/etc/group" file. Perhaps what we're seeing really is the reality of the situation. Maybe everything is straightforward and---on this computer---what you see is what you get? Let's reserve judgment on that.
The getent command can look at a single group for us. We'll look at the "devteam" group.
getent group devteam
We get exactly the same results as before. There is a way to dig deeper though.
The lid Command
The lid command is part of the libuser collection of tools. It was already installed on our Fedora 36 test computer but had to be installed on the Ubuntu 22.04 and Manjaro 21 ones.
Also, the command is called lid on Fedora and Manjaro, but on Ubuntu, you need to use libuser-lid.
To install the command on Ubuntu, type:
sudo apt install libuser
On Manjaro, libuser is installed from the AUR, so you'll need to use your favorite AUR helper. We used yay.
yay libuser
You can use libuser-lid to display group information about groups or users. To show the groups an individual is in, pass their user account name on the command line. On Fedora and Manjaro remember to use lid instead of libuser-lid.
sudo libuser-lib dave
To see the members of a group, use the -g (group) option along with the name of the group.
sudo libuser-lid -g devteam
Lo and behold, a user called "francis" has appeared as a member of the list. This is the first time we've seen him. He isn't listed in "/etc/group" and getent didn't discover him either.
Let's look at a few users with the groups command.
groups abigail
groups hayden
groups francis
- User "abigail" is in a group called "abigail" and two other groups, "resteam" and "devteam."
- User "hayden" is in a group called "hayden" and two other groups, "pvqteam" and "docteam."
- User "francis" is in a single group, the "devteam" group. It's notable that they are not in a group named "francis."
We know that every user must be a member of a primary group and that by default the primary group has a GID and name that match the user's UID and account name. It would appear there's something different about the user "francis."
Let's use the id command and see what the UID and GIDs tell us.
id abigail
id francis
User "abigail" has a UID of 1002, and a GID of 1002. They are in three groups, one of which is called "abigail." It has a GID of 1002. This is their default primary group.
User "francis" has a GID of 1019, which matches the GID of the "devteam" group. This user has either been assigned a new primary group, or the "devteam" group was set as their primary group when this user was added to the system.
Whichever one it was, only libuser-lid detected them and reported their presence in the "devteam" group.
The Devil's in the Details
So it's important to see the genuine details.
Groups are a great way to set up collaboration, just as long as you know who you're opening it up with.