Whether you're new to managing users and groups or just need a quick refresher, this tutorial will sharpen your sys admin chops.
OK, class settle down, find your seats, fire up your Linux systems and follow along with me for this user and group administration tutorial. This article is your short course on user and group administration using some commands that you’ve perhaps never seen or used before. User management doesn’t have to induce hair pulling (yours or theirs) nor does it have to make you hate user’s existence. Following a single, simple rule will make your life as a system administrator easier: Give your users access to what they need, no more and no less.
Any salty system administrator (SA) will tell you that you’re supposed to manage users with group permissions, and that’s true, but you still have to create those users, place them into groups, remove users and manage user access. It is these basic user management activities that you’ll explore in this week’s post.
Let’s appease those rusty old system administrators by first learning about groups and how to manage them. Group definitions reside in the /etc/group file. A standard Linux /etc/group file contains the following information: groupname:x:groupid:user list.
The “x” in the group definition file is a deprecated placeholder for a group password.
To find out which groups you belong to, type groups at a command prompt.
By default on most Linux systems, when an administrator creates a new user account, the system automatically creates a group account with the same name as the user account. An SA can specify a group when he creates the account but the group must already exist.
Here are two illustrative examples:
# useradd fred
# grep fred /etc/passwd
# grep fred /etc/group
# useradd -g 100 -c "Bob Alobdob" bob
# grep bob /etc/passwd
# grep bob /etc/group
Why did the system return no response when you typed in grep bob /etc/group? It’s because the users group is Bob’s primary group. If users were a secondary group, Bob’s username would appear in the list. For example, create a new user with rpdusers (Group ID 504) as a secondary group.
# useradd -G 504 -c "Jon Shmon" john
# grep john /etc/passwd
# grep john /etc/group
A group must exist before you assign users to it. The groupadd command creates new groups with a specific Group ID (GID) and name.
# groupadd -g 1040 accounting
# grep 1040 /etc/group
You may also create a new group with just a group name and the system will assign a GID for you with the command, # groupadd groupname.
The groupmod command allows you to change the group name but the SA will have to change any files associated with the old group manually.
# groupmod -n accounting beancounters
# grep 1040 /etc/group
Note: Don’t confuse chgrp (changes group permissions) with groupmod (changes the name of a group).
You can remove a group with the groupdel command.
# groupdel beancounters
If you prefer to edit configuration files directly, although you shouldn’t, the vigr command edits the /etc/group file in a safe manner by setting locks so that only one administrator at a time can edit the file.
Administrators rely heavily on the “group” commands for group administration, user administration and in scripting those functions for automated solutions.
I call this collection of utilities the “user” commands because their functionality centers on user administration and not on action taken by the users themselves. Even if a user knows the location of these commands (/usr/sbin), they still can’t issue them without root privilege.
For example, a clever user on your system tries to issue useradd and vipw.
$ /usr/sbin/useradd steve
useradd: Only root may add a user or group to the system.
vipw: Couldn't lock file: Permission denied
vipw: /etc/passwd is unchanged
The User commands have their Group analogs; you add a new user with useradd, modify a user account with usermod and delete a user account with userdel. And you edit the /etc/passwd file directly with vipw. You’ve already seen the useradd command in action in the Group Commands discussion.
The usermod allows SAs to alter any user account attribute including the user’s real name (comment field), home directory name, account expiration date, disabling functionality, group add and change, login name, account locking and unlocking, alter the user’s shell and more.
# grep khess /etc/passwd
# usermod -c "Ken Hess" khess
# grep khess /etc/passwd
The usermod command requires some restraint and careful typing when issuing commands that can make a user account unusable. Let’s say that Bob Alobdob, from an example in the Group discussion, wants his login name and home directory changed to robert.
# usermod -d "/home/robert" -m -l robert bob
# grep robert /etc/passwd
Notice how I explicitly entered “/home/robert” in the command? If you don’t specify the whole path, Robert won’t have a home directory nor will its contents exist anymore. The command, as shown, changes his current home directory from /home/bob to /home/robert, his login from bob to robert and the -m moves the contents of his “bob” home directory to his “robert” home directory. User permissions change to robert as well for all files in his home directory.
Note: You cannot change the login name of a currently logged in user.
The userdel command’s function might seem obvious to you but you might surprise yourself after issuing the command to find that the user’s home directory is still intact.
Why would any programmer allow that directory to remain as clutter on your home filesystem? This is actually a failsafe mechanism and you should thank the thoughtful programmer who maintains userdel.
What if two user names only differ by a single letter and you removed the wrong one? The incorrectly deleted user’s home directory and files were wiped from the system with a slip of your finger. With the failsafe mechanism in place, you have to manually remove the home directory and hopefully you would catch your error before doing so.
This introduction to user and group administration will point you in the right direction in your own duties as a new system administrator. Remember to think in terms of groups and add users to those groups as needed. Use the administrative tools and utilities provided to you and avoid directly editing any system file.
Have you ever wanted to see more information from your system than proc files or dmesg could give you? Well, your search is over. There are native tools that give you more than you imagined and we’ll have a look at them next week.
Kenneth Hess is a Linux evangelist and freelance technical writer on a variety of open source topics including Linux, SQL, databases, and web services. Ken can be reached via his website at http://www.kenhess.com
. Practical Virtualization Solutions by Kenneth Hess and Amy Newman is available now.