Understand what users and groups are, and how the files which define them are structured.
- [Instructor] On a Linux system we can create users and groups in order to more precisely control access to files and resources. A user corresponds to a human that will use the system or a servicer application that needs its own entity to run as. A group is a collection of users defined for a specific purpose. We can specify whether these users and groups can login to the system or how much storage they can consume or whether they are able to use the super user privileges to make changes to the system. We can set where their data is stored, what shell they use when they login and whether they need to change their password.
Users and groups are at the heart of security in a multi user system. Even on a cleanly installed system, you'll notice when you start looking around that there are a handful of users and groups that already exist on your system. These are created by the system or by installed software in order to scope access to particular things rather than having everything running as the root user which would be insecure and messy. While our users and groups have human, readable names, the system keeps track of them as numbers with UID's, or User IDs, and GIDs, or Group IDs.
When we create a user it becomes the only member of a group with the same name and we can add the user to other groups as well depending on what we want that user to have access to. The list of users is maintained in the etc/password file and the groups are maintained in the etc/group file. We don't edit these directly, but instead we have a selection of tools that let us create, modify and delete users and groups and find out information about them. But let's take a look at the format of these files so we know what they represent and then we'll take a look at making changes to users and groups.
In the etc/password file here, which is readable by everyone in the system but only writeable by root, there are seven fields for each user and they're separated by colons. For my user here, it looks like this. The first field is the username, what I'd type to login and that can be up to 32 characters long with no spaces. The second field, which shows up as an X, represents the fact that the user's password is stored in the shadow file. Shadow is only readable by root and members of the shadow group and only root can write to it.
We'll take a look at the shadow file in a moment. The third field in the password file is the UID, or User ID. The numeric representation of the user. Typically, normal users start at number 1,000 and go up from there as you add more users. They used to start at 500. The root user has user ID zero and system accounts start from there. So, generally speaking, a user ID less than 1,000 is a system account or an account for some software that was installed. And 1,000 or over are users created by the administrator for people or for some other purpose.
The fourth field is the numeric group ID, or GID, of the user's primary group. A user can be a member of more than one group but the primary group is listed here. And the others are listed in the group file that we'll see in just a moment. The fifth field here is a description or comment field. Usually this is where a human friendly name is stored like a full first and last name and it can also contain information like an office or phone number depending on how the standards of your system are set up. That's called GECOS and we'll get into that more later on.
You may see some commas separating empty fields if you're not using them. For users added by the system or by software, this field will often have a little bit more descriptive text to help you know what the account it for. The sixth field shows the path to the user's home directory where their stuff is stored and where they'll start out when they log into the system at the command line. And the seventh field is the user's default shell. Usually it'll be set to bash but for some accounts that aren't permitted to login it'll be set to no login, which refuses to let the user enter commands.
Or to false, which according to the manual does nothing unsuccessfully which, depending on how you look at it is either kind of inspirational or somewhat depressing. Both of these commands help to prevent users from getting to an interactive shell if they're not supposed to login. The shadow file that I mentioned earlier is the file where the encrypted passwords for users are stored. Let's take a look at some entries here. The entries in this file have nine fields though only two of them are really required. There's more detail about these fields in the manual page for shadow so I'll just go over the high points here.
The first field, the login name, is the name of the user on a system for which the password corresponds. The second field is the encrypted password, which is hard to reverse engineer but not impossible. That's why it's important to ensure that this file doesn't get lax permissions set on it. If an account is locked the string will start with an exclamation mark. A star or asterisk in this field means that there's no password set and that user can't login directly. The third field is the date of the last password change expressed in days since January 1st, 1970.
That's the beginning of time in the Unix world called, The Unix Epoch, and while we normally see epoch times in seconds since January 1st, 1970, in this case it's days. If this is set to zero it means that the user will be prompted to change their password on the next login. If it's empty, that means that the features that keep track of how old the password is are disabled. The fourth field is the minimum password age and the fifth is the maximum password age. Empty fields here mean there are no minimum or maximums. In my case here, the maximum is 99,999 days or almost 300 years, which effectively is no limit on the age of the password.
If you plan to live longer than that be sure to mark your calendar so you don't forget to change your password. The sixth and seventh fields here are the password warning period and inactivity period, and again, if they're empty it means there isn't a limit set. I have seven here in my sixth field, the warning field, so seven days before my password expires I'll start to get a warning that it's expiring when I login. The eighth field here is the account expiration date in days since January 1st, 1970. If it's blank the account won't expire. If a value is set, the system won't let the user login after the date of expiration.
And the final field here, number nine, is considered reserved for future use. The group file is where the system keeps track of membership in groups. Users can be a member of more than one group and groups are helpful when we're working with permissions or want to specify access to more than one user at a time. The group file has lines with four fields. The first field is the group name and then the group password in an encrypted fashion if there's one set. Group passwords aren't very widely used but the functionality does exist.
The third field is the numeric group ID and the fourth field is a comma separated list of users that are members in the group. We can explore the group membership of a user with the groups command and if we want to see the user and group IDs as well, we can use the ID command.
- Creating, modifying, and deleting user accounts
- Creating and modifying groups
- Configuring and monitoring user resources
- Configuring permissions to allow group collaboration
- Working with pluggable authentication modules (PAM)
- Managing user and group information with an LDAP directory
- Authenticating clients with Kerberos