% CST8207 Assignment 12 - Linux User and Group Management % Ian! D. Allen - - [www.idallen.com] % Fall 2013 - September to December 2013 - Updated 2017-05-31 12:16 EDT - [Course Home Page] - [Course Outline] - [All Weeks] - [Plain Text] Due Date and Deliverables ========================= > **Do not print this assignment on paper!** > > - On paper, you will miss updates, corrections, and hints added to the > online version. > - On paper, you cannot follow any of the [hyperlink URLs] that lead you > to hints and course notes relevant to answering a question. > - On paper, scrolling text boxes will be cut off and not print properly. > You must have your own CentOS virtual machine (with root permissions) > running to do this lab. You cannot do the lab on the Course Linux Server > because you do not have root permissions on that machine. - **Due Date**: `23h59 (11:59pm) Friday December 6, 2013 (end of Week 14)` - Your last assignment will also be due at the end of Week 14. Don't delay. - College policy does not allow assignments to be due after the term ends on December 6. - Late assignments or wrong file names may not be marked. Be accurate. - **Available online** - Version 1 -- 22:30pm Sunday November 17, 2013 - Version 2 -- 12:10pm Monday November 18, 2013 (New Due Date) - **Prerequisites** - All [Class Notes] since the beginning of term. - All your previous [Assignments]. - Completed [CentOS Virtual Machine] installation. - Completed [CentOS VMware Tools] installation. - An ability to **READ ALL THE WORDS** to work effectively! - **Deliverables** 1. One text file uploaded to Blackboard according to the steps in the [Checking Program] section below. 2. Directory structure created and left for marking on the [Course Linux Server] (**CLS**).\ **Do not delete any assignment work from the CLS until after the term is over!** 3. Accounts and directory structure created and left for marking on your own [CentOS Virtual Machine].\ **Do not delete any assignment work from your CentOS VM until after the term is over!** **WARNING:** Some inattentive students upload Assignment #12 into the Assignment #11 upload area. Don't make that mistake! Be exact. Purpose of this Assignment ========================== 1. Practice managing [Users and Groups] in your own virtual machine. Introduction and Overview ========================= This is an overview of how you are expected to complete this assignment. Read all the words before you start working. > Do not print this assignment on paper. On paper, you cannot follow any of > the hyperlink URLs that lead you to hints and course notes relevant to > answering a question. 1. Complete the readings in your weekly [Class Notes][All Weeks]. 2. Do the **Tasks** listed below, in order. - **READ ALL THE WORDS** to work effectively and not waste time. 3. Verify your own work before running the **Checking Program**. 4. Run the [Checking Program] to help you find errors. 5. Submit the output of the [Checking Program] to Blackboard before the due date. > Since I also do manual marking of student assignments, your final mark may > not be the same as the mark submitted using the current version of the > [Checking Program]. I do not guarantee that any version of the [Checking > Program] will find all the errors in your work. Complete your assignments > according to the specifications, not according to the incomplete set of > mistakes detected by the [Checking Program]. When you are finished the tasks, leave the files and directories in place as part of your deliverables. **Do not delete any assignment work until after the term is over!** Assignments may be re-marked at any time; you must have your term work available right until term end. The CLS Source Directory ------------------------ All references to the "Source Directory" below are to the CLS directory `~idallen/cst8207/13f/assignment12/` and that name starts with a *tilde* character `~` followed by a userid with no intervening slash. The leading tilde indicates to the shell that the pathname starts with the HOME directory of the account `idallen` (seven letters). Commands, topics, and features covered -------------------------------------- This is a Users and Groups assignment. Review course notes [Users and Groups]. Use the on-line help (`man` command) for the commands listed below for more information. - `chown` -- (change owner) Change the owner and/or group of an existing inode (needs `root` privilege) - `gpasswd` -- administer groups: set group administrator users, set group members, add and remove users from a group, change or remove the group password - `groupadd` -- add a new group to the `/etc/group` file - `groupdel` -- remove a group from the `/etc/group` file - `groupmod` -- modify group name, number, password account information in the `/etc/group` file - `groups` -- list the groups you (or another account) are in (from `/etc/group`) - `id [user]` -- display current account, current groups, and SELinux security context information - `newgrp` -- start a new shell with the permissions of a different group (similar to `su`) - `su [-] [user]` -- (substitute user) Become another user (default `root`), with that user's permissions - `sudo` -- do a command or start a shell (default with `root` permissions), configured via `visudo` and the file `/etc/sudoers` - `useradd` -- add a new user account and home directory - `userdel` -- delete an account (and possibly the home directory as well) - `usermod` -- modify account information (and possibly home directory as well) - `whoami` -- (who am I?) Display current account userid - `yum` -- install CentOS (Red Hat) software package Correct user, command lines, and command output ----------------------------------------------- - Parts of this lab are done as different non-root users. Other parts are done as the `root` user. Pay attention to which part is done by which user. After your configure `sudo` below, use the `sudo` command to run individual commands as `root` -- don't use a `root` subshell. - If you start a `root` subshell (not recommended -- use `sudo` instead), your prompt will tell you if you are the `root` user by changing to include a `#` character instead of a `$` character. You can also use the commands `id` or `whoami` to show your current userid. - Some answers require you to record **command lines**. Do **not** include the shell **prompt** with your command lines. Give only the part of the command line that you would type yourself. - Make sure you know the difference between a command **line** (which is what you type into the shell) and command **output** (which is what the command displays on your screen). Pay attention to whether the question asks you to record the command line or the command output. Backup and Recovery ------------------- 1. Take a snapshot of your virtual machine before you begin each section of this lab so that you can recover back to the snapshot if needed. You can delete the unused snapshots if everything works well. 2. You may find it useful to also make a backup copy in a safe place of the `/etc/passwd` file and its **shadow** and the `/etc/group` file and its **shadow**. You can compare the old and new files to know what has changed during this lab, and you can recover these files without reverting everything back to a snapshot. Use a remote login, not the VMware console ------------------------------------------ I recommend that once you have booted your CentOS VM, you connect to it and work using a remote login session (e.g. `ssh` or `PuTTY`) where copy-and-paste works and where you can have multiple simultaneous connections into the VM. The VMware console is not friendly. Tasks ===== - Do the following tasks in order, from top to bottom. - **READ ALL THE WORDS!** and do not skip steps. - Pay attention as to which tasks must be done in your own [CentOS Virtual Machine] and which must be done in your account on the [Course Linux Server]. - Your instructor will mark on the due date the work you have in your account on the CLS. Leave all your work on the CLS and do not modify it. - **Do not delete any assignment work from the CLS or your CentOS VM until after the course is over.** Set Up ------ 1. Create your `assignment12` directory on the CLS in the usual place. 2. Before you begin this assignment, create a snapshot of your [CentOS Virtual Machine], as mentioned above. - Enter a comment explaining where and when you took this snapshot. - You can restore back to this snapshot if anything goes wrong. Run the [Checking Program] to verify your work so far. CentOS: Install the `man` and `mail` commands --------------------------------------------- Review [Package Management]. 1. Install the `man` package. 2. Make sure `man man` works. 3. Install the `mailx` (note the spelling) package. 4. Make sure `mail -V` prints a version number. Run the [Checking Program] to verify your work so far. CentOS: The `sudoers` group and `/etc/sudoers` ---------------------------------------------- Only authorized accounts can use the `sudo` command. We will first create a special `sudoers` group. The `sudo` command will be configured to permit any account in this group to become the `root` user and run any command with full `root` privileges. 1. Login to your [CentOS Virtual Machine] as the `root` user (the only user). 2. Create a special group for users who will be permitted to use the `sudo` command, as follows: a. In the CentOS `man groupadd` manual page, read about the `-r` *system group* option. b. Use the `groupadd` command and an option to create a new *system group* called `sudoers` - Make sure the group is created as a **system group** (which means the group number used will be less than 500) c. Make sure the new group appears in the system group file and has a group number less than 500. d. If you did it wrong, use `groupdel` to delete it and start over. 3. Enable `sudo` to use the new `sudoers` group, as follows: a. Make a backup of `/etc/sudoers` (for example, `/etc/sudoers.bak`) b. If you know `vim`, edit the `sudoers` file with the `visudo` command. - If you still haven't learned any `vim` commands, and you have installed the `nano` editor, you can use this instead: `# EDITOR=nano visudo` c. In your editor, search for the comment line `# %wheel ALL=(ALL) ALL` - Read the comment line directly above it to see what this line does. - Note the leading `%` character on the example line for the `wheel` group d. Following the model of the above `%wheel` line, copy and create a new line (not a comment!) that allows anyone in the new `sudoers` group to run all commands. - Remember to prefix the group name with the `%` character. - Use the `%wheel` line as the model for your new line. e. Ensure there is no comment character `#` at the front of the line you just created. The line must start with `%` followed by the new group name (*not* the `wheel` group name). f. Save the `/etc/sudoers` file and quit the editor. 4. Use the `diff` command to do a file difference between your backup file `/etc/sudoers.bak` and the new `/etc/sudoers` file. Only one line should be added -- the new `%sudoers` line. If not, restore the file (or restore a previous snapshot) and make the changes again. Run the [Checking Program] to verify your work so far. CentOS: Creating a System Administrator Account ----------------------------------------------- In this section you will create your own system administration account on your CentOS VM. This personal account can be customized for you. > Do not add extensive customization to the `root` account on a system, since > such customization may not suit all `root` users of the system and may > break automated programs that need to become the `root` user. Review [Users and Groups]: - The CentOS `useradd` command creates a new account, storing information about the account in the `/etc/passwd` file and about the account groups in the `/etc/group` file. It also creates a HOME directory for the account and places standard start-up files into it. - The `passwd` command sets a password for an account, storing the password in the *shadow* password file named `/etc/shadow`. An account cannot be used until a password has been set. Group passwords (rarely used) are stored in the *shadow* group file `/etc/gshadow`. References to man pages below will be to **CentOS** man pages, not **CLS** man pages. **CentOS** Linux and **Ubuntu** Linux are different distributions and they sometimes have different documentation and programs. 1. Login to your [CentOS Virtual Machine] as the `root` user (the only user). 2. Make sure you have configured the `sudoers` group in the previous section. - This should find one line: `fgrep 'sudoers' /etc/group` - This should find one line: `fgrep '%sudoers' /etc/sudoers` 3. Take a VMware snapshot that you can return to if things go wrong. - Enter a snapshot comment explaining where and when you took this snapshot. 4. In the CentOS `man useradd` manual page: - In the **SYNOPSIS** syntax, note where the new **LOGIN** name must be used on the `useradd` command line. (It's always the **last** thing on the command line.) - Read about the `--comment` option and following argument used to define your *full name*. The (quoted) full name argument must immediately follow the option on the command line. See below. - Read about the `-r` *system account* option and how using it will require you to use the `-m` option as well. - Read about the `-m` option. You must use this, too. - You will need to use all three of these options correctly. 5. Following the **SYNOPSIS** syntax given in the `useradd` man page, add a new **system account** with the following settings: - **LOGIN**: Use your eight-character College/Blackboard/CLS username. - **COMMENT**: Copy and paste the exact text used for the fifth field of your own account line in `/etc/passwd` on the CLS: - The fifth field in `/etc/passwd` is called the **GECOS** field or **user's name or comment** field. - The text you must copy and paste from the CLS and use as a comment field on CentOS is in the form: "*Firstname* *Lastname* `- CST8207-13F-4NN`" where *Firstname* and *Lastname* are *your* name and *4NN* is your three-digit lab section number. - Copy and paste all this information from your entry in the CLS password file to be the (quoted) argument immediately following the `--comment` option. - Make sure the account is created as a **system account** with no password expiry. - Use the option to create the HOME directory at the same time. 6. After creating your account with `useradd`, verify it: a. Search for the newly created account line in the password file: - Make sure it has the correct **GECOS/comment/name** field that should be a copy of the same field on the CLS. - To be a system account, the userid number for the account must be less than 500. b. Run `id abcd0001` where *abcd0001* is your new account name. - Verify that all numbers are less than 500, indicating a system account. c. Make sure the newly created account also has a HOME directory created in the file system. Note that some default hidden files have been put into the HOME directory, copied from `/ets/skel`. 7. If you didn't succeed in creating the account and HOME directory correctly, you may restore your snapshot and try again or delete the account using `userdel -r` and try again. 8. Adjust permissions of the new account directory, if necessary, as follows: a. Set the permissions (mode) of the new HOME directory for your new account such that: - The owner (that is, you) can do everything, but - group and other users can do nothing (no permissions). 9. Set a password for your new sysadmin account, as follows: a. Review the section "Choose a hard-to-guess password" in `man passwd`. b. Assign your new account a strong password that you can [remember]. Warning: If you do not type the *username* argument to the password command, you are changing the password of the account that you are signed in with (i.e. the `root` account!). Do **not** change your `root` password! Change the password of your new non-root account. 10. Test your new account (from your current `root` shell): a. Run `su --login abcd0001` where *abcd0001* is your new account name. This will start a login subshell with your account privileges. You should see no error messages. Type some commands. b. Exit the `su` subshell, which will return you to your `root` login shell. c. Run `ssh abcd0001@localhost` where *abcd0001* is your new account name. - Say `yes` to accept the new host key. - Enter your new sysadmin account password. - If the password doesn't work, you probably changed the `root` password by mistake in an earlier step. Fix it and try again. - Upon success, you will be logged in as your sysadmin account. - Type `who` to see who is logged in. Your new account should be there: # who root pts/0 2013-11-16 00:35 (172.16.174.1) abcd0001 pts/1 2013-11-17 21:23 (localhost) - Exit this login session to return to your `root` login. 11. Enable `sudo` for your new sysadmin account, as follows: a. Use the correct command and option to add your new account user to the existing `sudoers` group that you already created earlier. (Hint: All the command names you might need are listed at the start of this document, and again in [Users and Groups].) b. Check you work: make sure your account name appears beside the `sudoers` group name in the group file. If not, get help. 12. Test your new account's ability to use `sudo`, as follows: a. Log out (`exit`) from the `root` account. b. Log in to CentOS using your new system admin account. c. Look at `man sudo`, or search the course notes for how to use it. Pay attention to what password `sudo` requires! You should be able to do this: [abcd0001@abcd0001 ~]$ sudo pwd [sudo] password for abcd0001: # enter the abcd0001 password /home/abcd0001 [abcd0001@abcd0001 ~]$ sudo -i pwd /root [abcd0001@abcd0001 ~]$ sudo -s [root@abcd0001 abcd0001]# pwd /home/abcd0001 [root@abcd0001 abcd0001]# exit [abcd0001@abcd0001 ~]$ - The `-i` option (RTFM) functions similarly to the `--login` option of the `su` command. - For an interactive subshell (`-s`), your shell prompt should change from `$` to include the `#` character that indicates `root` privileges. Avoid running `root` subshells! d. If the `sudo` was unsuccessful, check the following: - Did you type your **own** password (not the `root` password) when prompted by the `sudo` command? - Is your sysadmin (non-root) user in the `sudoers` group? - Is there a line in the `/etc/sudoers` file that allows anyone in the `sudoers` group to run all commands? (Check your work.) 13. You must not proceed until you are able to obtain `root` shell privileges from your sysadmin (non-root) user account using both `su` (with the `root` password) and `sudo` (with your password). Test these now! 14. You may optionally remove `/etc/sudoers.bak` if everything is working correctly. But maybe you should keep it, just in case. Run the [Checking Program] to verify your work so far. Using `sudo` or using `su` -------------------------- Now that you have your own sysadmin account on CentOS, always log in to your Linux machines using your non-root sysadmin account. Many servers actually disable direct login by the `root` user; you have to log in as the sysadmin user and then use `sudo` or `su` to run `root` commands. For most actions that need `root` privilege, use the `sudo` command to make the account privilege change just for that command. Do not log in as `root` or run a `root` shell or subshell until you have more experience. If you do start a full `root` subshell using the `su` or `sudo -s` commands (not recommended), remember to `exit` your subshell to return to your previous account. Don't keep layering multiple subshells inside one another. CentOS: Creating your Assignments directory ------------------------------------------- 1. Log in to your new system administration account (not the `root` account!). - Always log in to your sysadmin account first. 2. Create the same CST8207 `assignment12` directory structure in your new sysadmin account HOME directory on CentOS as you have created on the CLS: `CST8207-13F/Assignments/assignment12` **This CentOS directory is the base directory for all pathnames in this assignment. Store your files and answers here on CentOS.** Pay careful attention to whether you are working on the CLS or CentOS, and which account you are using! Watch the userid and hostname values in your `PS1` prompt string! Most answer files in this assignment get stored on CentOS, not on the CLS. Run the [Checking Program] to verify your work so far. ### No `root` files in non-root accounts Files saved anywhere under your sysadmin HOME directory in CentOS should be owned by you, not by `root`. (The presence of `root` files in non-root accounts is often a sign that your machine has been cracked!) Do not leave root-owned files in your account. You should change the owner to you of anything you create as `root` in your account. To find files not owned by you in your account: [abcd0001@abcd0001 ~]$ cd [abcd0001@abcd0001 ~]$ echo "$USER" abcd0001 # your own userid not abcd0001 [abcd0001@abcd0001 ~]$ find . ! -user "$USER" -ls [... any non-abcd0001 files are listed here ...] If you find any files, you should use the `chown` command to fix these files to be your own userid and group. > Advanced users can modify the above `find` to send pathnames into `sudo` > running `xargs` with `chown`. See [Find and Xargs]. CentOS: `adduser` and `useradd` are the same -------------------------------------------- Do the commands in this section using your own non-root account. As mentioned above, all output files must be owned by you and saved on CentOS in the usual place for this assignment in your account (not in the `root` account!). On CentOS, `useradd` and `adduser` are the same command with two different names. On some versions of Linux -- Debian, Ubuntu, etc. -- `adduser` is a different command with different options. 1. On CentOS, try `man adduser` and then `man useradd` and see that they are exactly the same thing. (If the `man` command is not found, you missed a step, above. Go back and install it.) 2. On the CLS (not CentOS), try the same two `man` command lines and see that the two commands are different and have different `man` pages on the CLS. (The CLS runs Ubuntu Linux, which is a Debian-based distribution. CentOS is a Red Hat distribution.) 3. On CentOS, find the absolute pathnames of the two command names `adduser` and `useradd`. (Note: The `which` command won't find the location of these two commands when run as a non-root user. Which other command locates the pathname and manual pages of a command name? Review the "related commands" in the [Search Path] notes.) You will need these two absolute pathnames for the next question. 4. On CentOS, save into output file `adduser.txt` the two lines of output from a long `ls` listing of the two above absolute pathnames. Your file will be two lines, 20 words, and 130 or 135 characters. Look at the `ls` output lines in `adduser.txt`: - Do you see why `useradd` and `adduser` are the same command on CentOS? - Do you see why the `which` command did not work to find the absolute pathnames of either of these commands when run as a non-root user? (Hint: Who can execute the `adduser` command?) Run the [Checking Program] to verify your work so far. CentOS: The Simpsons Follies: `homer` and `flanders` ---------------------------------------------------- You will need `root` privileges (e.g. via `sudo`) to run account management commands. Remember not to run `root` subshells! Use your sysadmin account and `sudo`. For this section you will require two more ordinary user (non-root, non-system) accounts. We will use two names from **The Simpsons** television series. 1. Create an account named `homer` (no options needed) and then give it a simple password. 2. Create an account named `flanders` (no options needed) and then give it the same password. Run the [Checking Program] to verify your work so far. CentOS: The Simpsons Follies: documentation ------------------------------------------- Do the commands in this section using your own non-root account. As mentioned above, all output files must be owned by you and saved on CentOS in the usual place for this assignment in your account (not in the `root` account!). 1. Use some `id` commands to record the account information for each of the two Simpsons accounts into a `simpsons.txt` file. Your file will be two lines, six words, 105 characters; one line for each of the two new Simpsons accounts. 2. Extract the account information lines for the two new accounts from the system password file and save the information in a `simpasswd.txt` file. Your file will be two lines, two words, 84 characters; one line for each Simpsons account. Each password file line will have seven colon-separated fields in it. 3. Put the long `ls` listing of the absolute pathname of each Simpsons account HOME directory (not the contents of the directory -- just the directory itself) into a `simpath.txt` file, one per line. Your file will be two lines, 18 words, 119 or 125 characters. If you get **permission denied**, you aren't using the correct option to `ls` to show only the directory, not the contents. 4. Put the three-digit **numeric** permissions of either of the above HOME directories in a `simperm.txt` file. Your file will be one line, one word, four characters. (Remember why three digits in a file is saved as four characters? Review *Text file line end differences* in [File Transfer].) Run the [Checking Program] to verify your work so far. CentOS: The Simpsons in the Public Directory -------------------------------------------- We will create a `/public` directory in the system ROOT directory in which *any user* can create files. The directory will allow any user to create names in it (or remove names, or rename). Recall that the permissions on a directory are not the same as the permissions on the things named in the directory. Permission to change file names does not grant permission to change file content. **The SB Output File**: In the next steps, where you are required to save a command line or its output, **do** the command and then copy and **record** the command line or its output as a separate line into an output file `simpub.txt` that will be noted as *the SB output file* below. If you can't answer a question, leave a blank line in this output file. (The `vim` option `:set number` may be useful to you as you edit.) You will need to use a command that lets you start a subshell as another user. Review [Users and Groups]. Remember not to run `root` subshells! Use your sysadmin account and `sudo`. > You need to run commands as different users. You may find it helpful to > have separate windows open into your CentOS VM, with subshells in each > window running as a different user. Then, you can simply change windows to > change users instead of having to exit and enter subshells in the same > window. Be lazy! ### Creating a public directory that anyone can write 1. Use appropriate privileges to create a directory called `/public` under the top-level ROOT directory. The exact name is `/public` (*NOT* `/root/public` and *NOT* `./public` and *NOT* `public`!). (Who has permissions to create this directory? Act accordingly.) 2. Now, give the `/public` directory *full access permissions* for *everybody*. - You should be able to `touch` and remove a file in this new `/public` directory as any non-root account. Test this (not as `root`). 3. Start up a subshell that runs as the `flanders` user. (Optionally use a new window for this.) 4. As the `flanders` user, redirect the current date into a new `flanfile` file in the above `/public` directory. The file will be 6 words 29 characters. - If this fails, you didn't set the correct directory access permissions on the directory, above. 5. Record just the **owner** and **group** of the `flanfile` file as Line 1 in the SB output file (two words only). 6. Record the current **numeric** permissions of the `flanfile` file as Line 2 in the SB output file (three digits only). ### Removing (only) other permissions from a file 7. What command syntax removes (only) all **other** permissions from a file and *does not change* any existing **user** or **group** permissions, *no matter what they might be*? Use this command on the `flanfile` file. - Record the exact command line used as Line 3 in the SB output file. 8. Record the new resulting **numeric** permissions for the `flanfile` file as Line 4 in the SB output file (three digits only). ### Renaming and deleting other users' files 9. Start a subshell that runs as the `homer` user. (Optionally use a new window for this.) 10. As the `homer` user, try to display the contents of the `flanfile`. You should get a "Permission denied" error message; `homer` does not have permission to read the file content. - If you didn't get an error message, you didn't correctly remove *other* permissions from the file. Go back and try again. - If you get an error "No such file", you typed the wrong pathname. Try again. 11. As the `homer` user, rename the `flanfile` file (still owned by `flanders`) to have the new name `homfile` (in the same directory as `flanfile`). - No error message should print. 12. Do a long `ls` listing of that new name confirming that the renamed file is still owned by `flanders`. - Record the long `ls` output as Line 5 in the SB output file. 13. As the `homer` user, remove the `homfile` name. You will need to answer a question about write-protection, with `y`. - This name is the name of a file still owned by `flanders`. - The file had only one name; removing this one name means the data in the file (data owned by `flanders`) is now gone forever. - Verify that the `/public` directory is now completely empty. Understand clearly why `homer` can **rename** and then **delete** a file that he doesn't own and can't read. Review [Links and Inodes]. Run the [Checking Program] to verify your work so far. CentOS: The Simpsons one file multiple write permissions -------------------------------------------------------- Remember not to run `root` subshells! Use your sysadmin account and `sudo`. > You need to run commands as different users. You may find it helpful to > have separate windows open into your CentOS VM, with subshells in each > window running as a different user. Then, you can simply change windows to > change users instead of having to exit and enter subshells in the same > window. Be lazy! 1. Create a new empty file `/public/homflan` that has the **owner** and **group** of `homer` and `homer`. (Hint: You could create the empty file first, then use `chown` to change the owner and group.) - Do a long `ls` listing of the file and verify that both the owner and group are `homer`. 2. As the `flanders` user try (and fail) to append the `date` to the `/public/homflan` file. You should get "Permission denied". 3. As the `homer` user try (and succeed) to append the `date` to the `/public/homflan` file. No error message. 4. Change only the file **group** and group **permissions** so that *both* `homer` *and* `flanders` can read and write `homflan` but **others** cannot write the file. Do not change anything about the file except the group and the group permissions! Hint: `homer`, the owner of the file, will read and write the file using the **owner** permissions. Arrange that the non-owner will be in the **group** of the file and so **group** permissions will apply, allowing access. Other users will be neither the owner of the file nor in the group of the file, so "**other**" permissions will apply to them and they cannot write the file. 5. Test it as *three* users. Both `homer` and `flanders` should be able to append data to the file, while your sysadmin (non-root) account should *not* be able to append data. 6. Exit from all the Simpsons user subshells and return to your sysadmin account shell. Run the [Checking Program] to verify your work so far. CentOS: Star Wars account management ------------------------------------ Take a snapshot of your virtual machine. Review [Users and Groups]. Remember not to run `root` subshells! Use your sysadmin account and `sudo`. - This section uses the `usermod` and `groupmod` commands. - The `usermod` command modifies user account attributes, as recorded in the **password** and **group** files. - The `groupmod` command modifies **group name**, number, and password, as recorded in the **group** file. - Use **only** these two commands to make the following section's account and group changes. Do **not** use any other commands to make these changes unless told to do so. Do not text-edit any account files; use the commands designed for the purpose. - Remember not to run `root` subshells! Use your sysadmin account and `sudo`. **The WA Output File**: In the next steps, where you are required to save a command line or its output, **do** the command and then copy and **record** the command line or its output as a separate line into an output file `starwars.txt` that will be noted as *the WA output file* below. If you can't answer a question, leave a blank line in this output file. (The `vim` option `:set number` may be useful to you as you edit.) 1. Create an account named `luke` (no options needed). 2. Give the new `luke` account a simple password. 3. Run a long `ls` listing on the new HOME directory (just the directory, not the contents) of the new `luke` account. - If you get **permission denied**, you aren't using the correct option to `ls` to show only the directory, not the contents. - You should see one line of information about the directory itself. Save the one line as Line 1 in the WA output file. 4. Search for lines containing `luke` in the four system accounting files (in the password and password shadow files and in the group and group shadow files -- four files in total). When you see four lines of output, put them into a separate `luke.txt` file. Your file should contain four lines that contain `luke`. ### Modifying a user account and group -- `usermod` and `groupmod` 4. Use a command to modify the **login** name of the `luke` account to be `darth` - Record the exact command line used as Line 2 in the WA output file. - Confirm the change by looking in the system password file: The `luke` user should be renamed to `darth`. - Run `id luke` and confirm that it **fails** with "No such user" - Run `id darth` and confirm that `darth` exists, but the account is still in the group named `luke`. - Run `ls -ld` on the HOME directory for this account (which hasn't changed) and note that the owner has changed, but not the group (it's still `luke`). - If it didn't work, restore the snapshot and try again. 5. Use a command to modify the **group** name of the `luke` group to be `darth` - Record the exact command line used as Line 3 in the WA output file. - Confirm the change by looking in the system group file: The `luke` group should be renamed to `darth`. - Run `id darth` and confirm that the account is now in the group named `darth`. - Run `ls -ld` on the HOME directory for this account (which still hasn't changed) and note that both the owner and group have been changed. - If it didn't work, restore the snapshot and try again. 6. The new `darth` account still uses an unchanged home directory of`/home/luke`. Use a command to change and move (in one command line) this old home directory from its current `luke` name to the new name `sith` - Record the exact command line used as Line 4 in the WA output file. - Use both `-d` and `-m` strictly according to the man page. - Use the correct absolute path for the new HOME directory. - Run `ls -ld` on the new changed and moved HOME directory for this account and confirm that both the owner and group are still `darth`. - If it didn't work, restore the snapshot and try again. 7. Check your work: - Use a command to search in the four system accounting files and make sure the word `luke` does not appear anywhere in those four files. - Start a login subshell in the `darth` account using `su`. There should be no errors. - Exit the `darth` subshell and return to your sysadmin account shell. ### Changing shells with `chsh` 8. Use the appropriate option to the `chsh` command to print the list of possible shells (four lines). 9. Change the shell for `darth` to be the one that prevents logins. (Choose the shell pathname that allows "**no logins**".) 10. Try to start a login subshell in the `darth` account using `su`. You will be rejected with "This account is currently not available." Run the [Checking Program] to verify your work so far. ### Modifying a user account and group -- `usermod` and `groupmod` 11. Create an account named `obiwan` (no options needed). 12. Give the new `obiwan` account a simple password. 13. Search for lines containing `obiwan` in the four system accounting files. When you see four lines of output, put them into an `obiwan.txt` file. Your file should contain four lines that contain `obiwan`. 14. Use the same commands as before to move the new `obiwan` account and group to be the new name `yoda` with home directory `master` (in the usual place for home directories). - Make sure `obiwan` is completely gone from all system accounting files. - Make sure the new `master` home directory is in the right place and has the correct owner and group. - Make sure you can start up a subshell in the `yoda` account without errors. (And exit that subshell!) Run the [Checking Program] to verify your work so far. CentOS: Group management: The Megadeth Project ---------------------------------------------- - This section uses some commands you have not used before. - Every command you need to use is mentioned in the opening page of this assignment document and is described in the lecture notes on [Users and Groups]. Become familiar with this list of commands before you continue, so that you know what command name to choose below. Every command also has a man page. - You do not need to text-edit any files in this section. All the commands you need are noted at the top of this document (and again in the [Users and Groups] course notes). **RTFM**! ### Requirements for Megadeth Group Management The four-person band [**Megadeth**] (note the unusual spelling of **Megadeth**) uses the following work approach and has the following **Requirements**: A. Song files can be created by one band member who is the single **group administrator** account. Only this one **group administrator** account can create, delete, modify and write song files. B. Files must only be readable (not writable or removable) by the other three non-administrator group (band) members. These three ordinary band members must only be able to read the song files, not change or remove or rename them. C. Anybody who is not a **band member** is not allowed to view song files. You must prevent all public access of any kind to the song files. - Follow the directions below to create accounts and directories that implement the above **Requirements**. Some of the work will need to be done as the `root` super-user. (Only the `root` user can create new accounts.) Most group maintenance work can be done as the band member who is assigned to be the **group administrator**. - The four **Megadeth** band members are (get the name and account spellings correct! Case matters): - [**Dave Mustaine**] -- login name: `mustaid` - [**David Ellefson**] -- login name: `ellefsd` - **Chris Broderick** -- login name: `broderc` - **Shawn Drover** -- login name: `drovers` ### Creating and configuring the Megadeth Working Group Remember not to run `root` subshells! Use your sysadmin account and `sudo`. 1. Take a VM **snapshot** before you begin this section, so you can return here if you make many mistakes. Keep a separate record of the exact commands you use in this section, for study purposes. 2. Create the four new band accounts. Use the `--comment` option to include each band member's **full name** in each account you create. - Remember to **quote** shell arguments containing blanks. - Don't worry about any special groups yet. Just create the accounts with their full names and no other options. - If you forget to include the full names when you create the accounts, you can modify the information with the `usermod` command afterward. 3. Give all four accounts some simple passwords. 4. Use a command to add a new **group** named `megadeth` (spelled all lower case) to the system accounting files. - You have already used this command earlier to add a different group. - Do *not* make this `megadeth` group a *system group*. Keep it ordinary. - Verify that the new `megadeth` group is now in the system group file and has a numeric GID of 500 or greater. If not, delete it and try again. 5. Use a command to set band member **Chris Broderick** as the **group administrator** of the new `megadeth` group. - Verify that the `megadeth` group in the group shadow file lists Chris' account userid in the third field. If not, delete it and try again. 6. Log in (start a subshell) as the `megadeth` *group administrator*. Using his account, use a command four times to **add** each of the **four** band members to the `megadeth` group, one-by-one. - Only the *group administrator* can add members to the group. - The *group administrator* can only add users one-at-a-time. - Confirm that the system **group** file contains the new `megadeth` group with all **four** band members listed beside it. - Exit the Chris subshell when you are done adding four members. 7. Create a new song directory named `/home/music` (lower-case). 8. The band wants to store its song files under this `music` directory, with permissions that implement the **Requirements** given above. Set ownership and permissions for the `music` directory to implement the given **Requirements**: a. Which band account should be set as the **owner** of directory `music`? - Make it so. b. Which group should be set as the **group** of directory `music`? - Make it so. c. Which **permissions** should be set on directory `music`? - Make it so, so that the **Requirements** are met. ### Test Plan for the Megadeth Group Project You need to **verify** that the requirements have been **met** using a **Test Plan**. Here it is: 9. Become the **group administrator** and do these read/write tests: - Redirect the current `date` into a new file named `test` in the `music` directory. It should be possible without any errors. - Display the file on your screen to make sure the file has content you can read and write while you are logged in as the group administrator. - Exit the group administrator account when you are done testing. 10. Become a non-group-administrator band member and do these read-only tests:. - Make sure the member can read the `test` file, but can not change it, rename it, or remove it. 11. Become any other ordinary user (e.g. your own sysadmin account) and test for no access: - Make sure that the `music` directory cannot be listed or entered by any user who is not a band member. ### Finishing touch -- four symbolic links 12. Log in as each band member (four times) and create the shortest relative (not absolute) **soft link** (symbolic link) named `music` in the home directory that links up to `/home/music` so that each band member can then use the soft link to access the `/home/music` directory instead typing the entire pathname. When you are done ----------------- That is all the tasks you need to do. Check your work a final time using the [Checking Program] and save the output as described below. Submit your mark following the directions below. Checking, Marking, and Submitting your Work =========================================== **Summary:** Do some tasks, then run the **Fetch** and checking program to verify your work as you go. You can run the **Fetch** and checking program as often as you want. When you have the best mark, upload the marks file to Blackboard. The checking program resides on the [Course Linux Server], but your work is on your [CentOS Virtual Machine]. There is a new **Fetch** program that you must download and use on your CentOS Virtual Machine to copy information from your CentOS Virtual Machine to your account on the CLS so that the checking program can check it on the CLS. Once the **Fetch** program has fetched these files from your Virtual Machine to the CLS, you can run the checking program on the CLS to check what is saved in the files. When you make changes on your CentOS Virtual Machine, you need to run the **Fetch** program again on CentOS to update the saved files on the CLS. Simply running the checking program on the CLS will *not* update the saved files on the CLS. You must run the **Fetch** program below on your CentOS VM when you make changes on your [CentOS Virtual Machine]. Part I - Fetch and Check ------------------------ Do all the following steps on your [CentOS Virtual Machine]. Read through the whole list before you start typing anything. An example of what to type is given below the descriptions that follow. 1. Log in to CentOS using your system administrator (non-root) account. 2. Change to your existing CentOS `assignment12` directory containing all your answer files for this assignment. 3. As shown below, use `curl` to get a copy of the **Fetch** program from the given URL into a file named `do.sh`. - Make sure you end up with a file named `do.sh` in your `assignment12` directory. - Make sure the downloaded file is not a file of HTML and errors. It should start with `#!/bin/sh` and contain a few shell comments and commands, including another `curl` command. - You only need to download this **Fetch** program once per assignment. 4. As shown below, use `sudo` to run the `do.sh` script you just downloaded to CentOS, with the `USER` environment variable set to your own College/Blackboard/CLS account userid (do not use *abcd0001*). - You must use `sudo` to run the script. 5. This **Fetch** program will connect from CentOS to the CLS using your account name. It will copy files from CentOS to your `assignment12` directory on the CLS. It will then run the checking program on the CLS to check your work. You will need to answer one question about your IP address, and then wait and type in your CLS password. It will look something like this (use your userid, not *abcd0001*): - You must use `sudo` to run the script: CentOS$ hostname abcd0001 CentOS$ pwd /home/abcd0001/CST8207-13F/Assignments/assignment12 CentOS$ echo "$USER" abcd0001 CentOS$ curl -A mozilla http://teaching.idallen.com/cst8207/13f/notes/data/assignment12do.sh >do.sh [... various download statistics print here ...] CentOS$ sudo USER=$USER sh do.sh --------------------------------------------------------------------------- abcd0001: FETCH version 2. Connecting to CLS as USER='abcd0001' using ssh --------------------------------------------------------------------------- abcd0001: Use local Algonquin IP cst8207-alg.idallen.ca [y/N]? n abcd0001: Please wait; using ssh to connect to user 'abcd0001' on cst8207.idallen.ca ... *** COURSE LINUX SERVER *** abcd0001@cst8207.idallen.ca's password: # enter your CLS password --------------------------------------------------------------------------- idallen-ubuntu assignment12fetch_server.sh version 4 run by abcd0001. Please wait; collecting info from abcd0001 Virtual Machine --------------------------------------------------------------------------- VM files collected into CST8207-13F/Assignments/assignment12/abcd0001.tar.bz on CLS. Now running checking program for abcd0001 on CLS: [... checking program output appears here ...] - You only need to run the first `curl` line once per assignment, to get a copy of the `do.sh` script. - Once you have the `do.sh` script, you can use `sudo` to run the `do.sh` script over and over to check your work as you make updates. ### Notes on the Fetch program - This **Fetch** program updates your saved files on the CLS and then runs the checking program on the CLS. If you only run the checking program on the CLS, it won't update the files from your CentOS VM and it will just check the exiting files saved under `assignment12` on the CLS. - The checking program is running on the CLS, not on your CentOS VM. At the start, the checking program will issue messages relevant to your account on the CLS (e.g. errors in your CLS `.bashrc` file or world-writable files on the CLS). These errors are on the CLS, not on your CentOS machine. Part II - Check and Submit -------------------------- When you are done with your assignment, you need to run the checking program one last time on the CLS and submit the output file, as follows: Do all this one last time on the [Course Linux Server] (not on CentOS): 1. There is a [Checking Program] named `assignment12check` in the [Source Directory] on the CLS. Create a [Symbolic Link] to this program named `check` under your new `assignment12` directory on the CLS so that you can easily run the program to check your work and assign your work a mark on the CLS. Note: You can create a symbolic link to this executable program but you do not have permission to read or copy the program file. 2. Execute the above "check" program on the CLS using its symbolic link. (Review the [Search Path] notes if you forget how to run a program by pathname from the command line.) This program will check your fetched CentOS work, assign you a mark, and display the output on your screen. (You may want to paginate the long output so you can read all of it.) Remember: The checking program does not fetch new files to the CLS from your CentOS VM. You must run the **Fetch** program on your CentOS VM to update the fetched files on the CLS so that the checking program can mark them on the CLS. You may run the "check" program as many times as you wish, to correct mistakes and get the best mark. **Some tasks sections require you to finish the whole section before running the checking program at the end; you may not always be able to run the checking program successfully after every single task step.** 3. When you are done with checking this assignment, and you like what you see on your screen, redirect the output of the [Checking Program] into the text file `assignment12.txt` under your `assignment12` directory on the CLS. Use the *exact* name `assignment12.txt` in your `assignment12` directory. Case (upper/lower case letters) matters. Be absolutely accurate, as if your marks depended on it. Do not edit the file. Make sure the file actually contains the output of the checking program! 4. Transfer the above `assignment12.txt` file from the CLS to your local computer and verify that the file still contains all the output from the checking program. Do not edit this file! No empty files, please! Edited or damaged files will not be marked. You may want to refer to your [File Transfer] notes. 5. Submit the `assignment12.txt` file under the correct Assignment area on Blackboard (with the exact name) before the due date. Upload the file via the **assignment12** "Upload Assignment" facility in Blackboard: click on the underlined **assignment12** link in Blackboard. Use "**Attach File**" and "**Submit**" to upload your plain text file. No word-processor documents. Do not send email. Use only "Attach File". Do not enter any text into the **Submission** or **Comments** boxes on Blackboard; I do not read them. Use only the "**Attach File**" section followed by the **Submit** button. (If you want to send me comments about your assignment, use email.) 6. Your instructor may also mark the `assignment12` directory in your CLS account after the due date. Leave everything there on the CLS. **Do not delete any assignment work from the CLS until after the term is over!** 7. Your instructor may also mark the files on your CentOS VM after the due date. Leave everything there on your CentOS VM. **Do not delete any assignment work from the CentOS VM until after the term is over!** Use the *exact* file name given above. Upload only one single file of plain text, not HTML, not MSWord. No fonts, no word-processing. Plain text only. Did I mention that the format is plain text (suitable for VIM/Nano/Pico/Gedit or Notepad)? **NO EMAIL, WORD PROCESSOR, PDF, RTF, or HTML DOCUMENTS ACCEPTED.** No marks are awarded for submitting under the wrong assignment number or for using the wrong file name. Use the exact name given above. WARNING: Some inattentive students don't read all these words. Don't make that mistake! Be exact. **READ ALL THE WORDS. OH PLEASE, PLEASE, PLEASE READ ALL THE WORDS!** -- | Ian! D. Allen - idallen@idallen.ca - Ottawa, Ontario, Canada | Home Page: http://idallen.com/ Contact Improv: http://contactimprov.ca/ | College professor (Free/Libre GNU+Linux) at: http://teaching.idallen.com/ | Defend digital freedom: http://eff.org/ and have fun: http://fools.ca/ [Plain Text] - plain text version of this page in [Pandoc Markdown] format [www.idallen.com]: http://www.idallen.com/ [Course Home Page]: .. [Course Outline]: course_outline.pdf [All Weeks]: indexcgi.cgi [Plain Text]: assignment12.txt [hyperlink URLs]: indexcgi.cgi#Important_Notes__alphabetical_order_ [Class Notes]: indexcgi.cgi#XImportant_Notes__alphabetical_order_ [Assignments]: indexcgi.cgi#XAssignments [CentOS Virtual Machine]: 000_centos_install.html [CentOS VMware Tools]: 000_centos_vmware_tools.html [Checking Program]: #checking-marking-and-submitting-your-work [Course Linux Server]: 070_course_linux_server.html [Users and Groups]: 700_users_and_groups.html [Package Management]: 520_package_management.html [remember]: http://xkcd.com/936/ [Find and Xargs]: 185_find_and_xargs.html [Search Path]: 400_search_path.html [File Transfer]: 015_file_transfer.html [Links and Inodes]: 455_links_and_inodes.html [**Megadeth**]: https://en.wikipedia.org/wiki/Megadeth [**Dave Mustaine**]: http://www.youtube.com/watch?v=mYlUe-SDqA0 [**David Ellefson**]: http://www.youtube.com/watch?v=VXpjtWZn_vU [Source Directory]: #the-cls-source-directory [Symbolic Link]: 460_symbolic_links.html [Pandoc Markdown]: http://johnmacfarlane.net/pandoc/