* [Intro](#intro)

* [Creating User Accounts](#creating-user-accounts)

+ [`useradd`](#useradd)

+ [User Defaults](#user-defaults)

+ [`usermod`](#usermod)

+ [`userdel`](#userdel)

* [Group Accounts](#group-accounts)

+ [User Group Accounts](#user-group-accounts)

+ [Creating Group Accounts](#creating-group-accounts)

+ [Locked out of `sudoers` and Fixed](#locked-out-of-sudoers-and-fixed)

* [Managing Users in Complex Systems](#managing-users-in-complex-systems)

+ [Setting Permissions with Access Control Lists (ACL)](#setting-permissions-with-access-control-lists-(acl))

+ [Setting ACLs with `setfacl`](#setting-acls-with-setfacl)

+ [Setting Default ACLs](#setting-default-acls)

+ [Enabling ACLs](#enabling-acls)

+ [Adding Directories for Users to Collaborate](#adding-directories-for-users-to-collaborate)

+ [Creating Restricted Deletion Directories with Sticky Bits](#creating-restricted-deletion-directories-with-sticky-bits)

- This chapter is

- This chapter is about managing users in Linux. It does that in 3 main sections:

- First, we tackle user accounts: how to add, delete and change information about single users.

- Second, we treat user group accounts and see how we can create settings for a multiple users and what they can do by simply changing their group setting and by adding them or removing them from groups.

- Third, we look at more advanced ways of managing users such as ACLs and setting collaborative directories with set GIT bit and sticky bit.

- The **`-g`** option indicates a specific GID. Without it, the next available GID is assigned to the group.

- The **`groupmod`** command allows you to modify several attributes from a given group.

- ***I have stupidly managed to accidentally lock myself out of the sudoers files. I don't know what exactly caused this. Was it `usermod -G` or `usermod -g`.***

- To fix such a problem I had to boot the system in recovery mode by pressing the shift key during the booting process. Some screen showing an option for *recovery mode* appears. I click on root and, voilà, I'm logged in as root. I check the sudoers file and don't see my actual username, but see another one. I had deleted that user. Instead of modifying the sudoers file in this recovery mode I thought it'd be wiser to just add that user which is in the sudoers file. Before that I had to make the filesystem also writable because it's read-only in recovery mode. Making the filesystem writable is done with the following command:

mount -o rw,remount /

- The question now is: how do I secure my system so that only an authorized user can actually log in in recovery mode and fix problems like this!!?

- The user/group model is good in simple setups with few users. In more complex settings, this model becomes restrictive and suffers from such shortcomings as:

- Only one user and one group can be assigned to a file/directory.

- A regular user's ability to set permissions on different files/directories is limited.

- We sometimes need more users to share a file and regular users to have more freedom to set permissions on files and directories. We will do this using **access control lists (ACLs)** and *shared directories* (**sticky bit** and **set GID bit** directories).

- Basically, ACLs allow regular users to share their files and directories with certain other users and groups. A regular user can allow select users/groups to read/write/execute files without such files having open permissions.

- The following general rules apply to ACLs:

- To use ACLs on a filesystem, you must enable them when that filesystem is mounted.

- In Ubuntu, Fedora and others, ACLs are enabled by default on the filesystem created during installation of the system.

- If you want ACLs enabled on a filesystem you create/add after installation, you must set the acl mount option when that filesystem is mounted.

- ACLs are added to a file using the **`setfacl`** commands. Viewing ACLs on a file is done with **`getfacl`**.

- Only the owner of a file can set ACLs on it. If a user is assigned user/group permissions using `setfacl`, that user cannot change ACLs on that file.

- Because multiple groups/users can be assigned to a file, the permissions the user has on the file is the union of permissions assigned to the user and all the groups he belongs to. If I belong to sales which has read permission, and marketing which has write permission and development which has execute permission, the I have their permissions combined so I can read/write/execute the file.

- You set ACL permissions on a file using `setfacl` along with the **`-m`** option as in:

setfacl -m u:username:rwx filename

- You can remove these options using the **`-x`** option:

setfacl -x u:username filename

- When you run `ls -l` and see a file has a plus in its permissions as in **`rw-rw-r--+`**, this means ACLs are set on it and you can use `getfacl` to see what ACLs it has. Let's look at an example of what `getfacl` prints out:

- **`mask`** in the example above is the maximum permissions on the file including ACL and regular users and groups. In Fedora this mask cannot exceed the regular group permissions. This *might be true for Ubuntu as well.*

- You can set default ACL permissions on a directory so all files and directories created in that directory inherit those ACL permissions. In the following example, we set default ACLs on directory `/business/john` using **`d:`** and **`g:`** is for group sales. Each file or directory added to this directory have the same ACLs for sales (`rwx`):

setfacl -m d:g:sales:rwx /business/john

- Files/directories you create within this file might differently mainly due to the masking that dictates they cannot exceed the file's group permissions. Their **effective** permissions are union of the mask and the default ACL permissions.

- I don't understand what's going on here, so I'll just skip this for now!

- A fourth set of bits is usually ignored when using `chmod`. These bits can be used by `chmod` to set special permissions. These are the so-called **set user ID bit**, **set group ID bit**, and the **sticky bit**.

- The following table shows how these bits and their values work with `chmod`

| Name | Numeric value | Letter value |

| --- | --- | --- |

| Set user ID bit | **`4`** | **`u+s`** |

| Set group ID bit | **`2`** | **`g+s`** |

| Sticky bit | **`1`** | **`o+t`** |

- This section is about creating directories for collaboration, so we will just focus on the set group ID bit and sticky bit.

- By creating a GID directory, any file created in that directory is automatically shared with/assigned to users of that directory's group. Let's say we want to make `mabi3at` directory a collaborative file among sales users. We start by using a new chmod that includes a 4th number or its equivalent letter representation:

chmod 2775 mabi3at

- We assign the mabi3at directory to sales group, so users belonging to the sales group have permissions `775` on any file created in this directory. When a user belonging to the sales group creates a file in this directory, the group of the file is automatically sales, not the primary group of the user. I see how this can be more convenient than ACLs.

- Directories with the set GID bit have an **`s`** in their group permissions bit, which we can see by running ls -l:

drwxrwsr-x 2 am sales 4096 Apr 7 20:43 mabi3at

- By setting the sticky bit on a directory, you effectively prevent a user from deleting files that belong to other users. Imagine we have a collaborative directory where everyone can read everyone else's files, and can also add files to that directory. We cannot do this any other way. A user with the permission to write to a directory can create but also delete files in that directory. How can we get a user to only create files in a directory and delete her own but not delete other's files. This is the job of sticky bits which we can set using letter values as follows:

chmod o+t mabi3at

- Directories with the set sticky bit have a **`t`** in their permissions as in **`drwxrwsr-t`**.

- By the way, only the root user and the owner of the directory can delete files from this directory.