% Nick Urbanik <nicku@nicku.org>
% Copyright 2000 under the conditions of the GNU Free Documentation License,
% a copy of which is available at http://www.gnu.org/copyleft/fdl.html
% Copy and modify freely as long as this paragraph remains intact.
% Suggestions for improvement (and the improvements themselves!) welcome.
\chapter{Administering User Accounts and Permissions with {\pgn sudo}}
\label{cha:UserAccounts-and-sudo}
{\mns

\subsection{Objectives}

\begin{itemize}
  \item After completing this section, you will be able to:
  \begin{itemize}
  \item Create user accounts that include the user's full name, using
    the industry standard program {\cmdn useradd}

  \item Delete user accounts with {\cmdn userdel}

  \item Create and delete groups

  \item Add users to, and remove users from groups

  \item Set permissions on files and directories that enable and
    restrict access to users and groups of users.

  \item Use {\pgn sudo} to run administration programs without becoming root
  \end{itemize}
\end{itemize}

\section{System Administration without always being SuperUser}
\label{sec:not-root}

\begin{itemize}
\item Working as the SuperUser (root) all the time is a disaster
  waiting to happen.

\item Example: if you run {\pgn netscape} as root, and download a
  malicious Java or JavaScript program, it can execute with SuperUser
  privileges and destroy the server you are working on, and affect
  your career badly!

\item Trust me: be root as little as possible.  Never run X as root.
  If you are the system administrator, step one = make your own
  non-root account.  Always log in as yourself, not root.

\item So how to get work done?

\item Solution: {\pgn sudo}

\item Refer to the notes about configuring and using {\pgn sudo}
\end{itemize}

\section{Setting your PATH}
\label{sec:PATH}

\begin{itemize}
\item When you type a program name, the shell searches a list of
  directories for it.

\item The list of directories is stored in an {\kwd environment
    variable} {\var PATH}.

\item Programs for system administration are kept in directories {\fn
    /sbin} and {\fn /usr/sbin}.  (sbin = \textbf{s}ystem
  \textbf{bin}ary).

\item Normally these are not put on your path.
  
\item As a system administrator, it is good for you to put these
  directories onto your path, by editing \emph{your} login script
  (\emph{not} root's!)  $\sim${\fn/.bash\_profile} and adding the
  line:
\begin{verbatim}
PATH=$PATH:/sbin:/usr/sbin
\end{verbatim}%$

\item After saving your log in script, \emph{source} your log in
  script:
\begin{alltt}
$ \textbf{source \(\sim\)/.bash_profile}    
\end{alltt}%$

\item The alternative is to type the full path name for each system
  administrator command:
\begin{alltt}
$ \textbf{sudo /usr/sbin/useradd -c "Noris Lurka" nlurka}
\end{alltt}%$

\item \ldots otherwise you will see something like this:
\begin{alltt}
$ \textbf{sudo useradd user1}
sudo: useradd: command not found
\end{alltt}%$
\end{itemize}


\section{Linux is a Multiuser System}

\begin{itemize}
\item Linux is a \emph{multiuser} system

\item This is different from what you have experienced with Microsoft
  operating systems\footnote{Although the terminal server is changing NT into
  a multiuser system.}.

\item Many users can log into the computer at the same time (usually
  over the network using secure shell---see later)
  
\item All can run programs (graphical and in text mode) interactively
  on the one computer

\item Each user is protected by the operating system from accidental
  (and some malicious) damage from other users
\end{itemize}

\section{User account overview}

\begin{itemize}
\item Each user belongs to at least one \emph{group}

\item Each user has a \emph{user id} and one \emph{group id} for each
  group they belong to

\item These ids are integer numbers

\item All account information is stored in the following files:
  \begin{itemize}
  \item {\fn /etc/passwd} maps user name to user id,
    main group id, full name, home directory, and default shell
    (usually {\cmdn bash} for normal users)

  \item {\fn /etc/shadow} maps user name to password, holds user password
    aging policies

  \item {\fn /etc/group} maps group names to group ids

  \item {\fn /etc/gshadow} which holds group passwords
  \end{itemize}
\end{itemize}


\section{{\fn password} file}
\label{sec:passwd-file}

\begin{itemize}
\item It is a text file
  
\item You looked at this file in sections
  \ref{sec:overview-pipes-anon-io-continued} and
  \ref{sec:overview-pipes-and-tools}, and in
  question~\vref{que:sort-passwd}.  It is also discussed in some
  detail in section~\vref{sec:passwd}.

\item If deleted, no one can log into the system!

\item It is used when you type {\cmdn ls -l} to show user names
  rather than user ids.

\item The 7 fields are separated by colons `\texttt{:}'

\item The manual page is in section 5 (section 5 is about file
  formats); read it with
\begin{alltt}
$ \textbf{man 5 passwd}
\end{alltt}%$

\item In the old days, second field was the password, but not now.
\end{itemize}


\section{Example {\fn passwd} file}
\label{sec:example-of-passwd-file}

Here is part of a {\fn passwd} file:
{\myss
\begin{verbatim}
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:
daemon:x:2:2:daemon:/sbin:
adm:x:3:4:adm:/var/adm:
lp:x:4:7:lp:/var/spool/lpd:
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:
news:x:9:13:news:/var/spool/news:
uucp:x:10:14:uucp:/var/spool/uucp:
operator:x:11:0:operator:/root:
games:x:12:100:games:/usr/games:
gopher:x:13:30:gopher:/usr/lib/gopher-data:
ftp:x:14:50:FTP User:/home/ftp:
nobody:x:99:99:Nobody:/:
xfs:x:100:102:X Font Server:/etc/X11/fs:/bin/false
gdm:x:42:42::/home/gdm:/bin/bash
postgres:x:101:233:PostgreSQL Server:/var/lib/pgsql:/bin/bash
squid:x:102:234::/var/spool/squid:/dev/null
nicku:x:500:500:Nick Urbanik,C440,24368576:/home/nicku:/bin/bash
\end{verbatim}
}% End of \myss wrapped round this verbatim environment


\section{\fn group}
\label{sec:group-file}

\begin{itemize}
\item Maps group names to group ids
  
\item Maps users to additional {\kwd secondary} or {\kwd
    supplementary} groups (besides their \emph{primary group})
  
\item The \emph{primary group} is the group specified by the fourth
  field in the {\fn /etc/passwd} file.

\item Read the manual page with
\begin{alltt}
$ \textbf{man 5 group}
\end{alltt}%$

\item Here is part of a {\fn group} file:
{\myss
\begin{verbatim}
root:x:0:root
bin:x:1:root,bin,daemon
daemon:x:2:root,bin,daemon
sys:x:3:root,bin,adm
adm:x:4:root,adm,daemon
tty:x:5:
disk:x:6:root
lp:x:7:daemon,lp
mem:x:8:
utmp:x:101:
xfs:x:102:
floppy:x:19:
console:x:103:
gdm:x:42:
pppusers:x:230:
popusers:x:231:
postgres:x:233:
slocate:x:21:
squid:x:234:
nicku:x:500:pam
\end{verbatim}
}% End of \myss wrapped round this verbatim environment
\end{itemize}


\section{{\fn shadow} file}
\label{sec:shadow-file}

\begin{itemize}
\item Current Linux distributions default to using the {\fn shadow}
  file to hold passwords

\item If it doesn't, consider changing to a better distribution!

\item Holds the following information:
  \begin{itemize}
  \item Login name

  \item Encrypted password

  \item Days since Jan 1, 1970 that password was last changed

  \item Days before password may be changed

  \item Days after which password must be changed

  \item Days before password is to expire that user is warned

  \item Days after password expires that account is disabled

  \item Days since Jan 1, 1970 that account is disabled
  \end{itemize}

\item Must have permissions like this:
{\myfs
\begin{alltt}
$ \textbf{ls -l /etc/shadow}
-rw-------    1 root     root         1114 Oct 30 12:50 /etc/shadow
\end{alltt}}%$

\item Here is a line from an {\fn /etc/shadow} file:
{\myfs
\begin{verbatim}
root:$1$CBBmBWbw$OOH0LNS.gH1KXsMX6ACC2.:11175:0:99999:7:::134539268
\end{verbatim}}%$
\end{itemize}


\section{logging in}
\label{sec:login}

\begin{itemize}
\item Many programs for a user to login; examples shown on next slide

\item A group may also have a password (stored in the {\fn
    /etc/gshadow} file)

\item If a group has a password, and you know that password, you can
  become a member of that group with the command {\pgn newgrp}

\item You can change or add a group password with the {\pgn gpasswd}
  command.
\end{itemize}


\section{logging in---Pluggable Authentication Modules (PAM)}
\label{sec:pam}
\enlargethispage{\baselineskip}
\begin{itemize}
\item Many programs ask for a password.  Examples:
  \begin{itemize}
  \item {\pgn login}

  \item {\pgn slogin}

  \item {\pgn telnet}

  \item {\pgn ftp}

  \item {\pgn samba}

  \item {\pgn su}

  \item {\pgn gdm} (the Gnome login to X)

  \item {\pgn xscreensaver}

  \item {\pgn sudo}
  \item \ldots and many others (see {\fn /etc/pam.d/*})
  \end{itemize}

\item The login programs are \emph{very} important for security; one
  small mistake, and your system can be cracked.
  
\item To avoid replicating the code in every application, one library
  handles login for all these programs.  Called Pluggable
  Authentication Modules library (PAM)
  
\item Allows total customisation of login, including replacement or
  supplementing of password file by other systems, such as:
  \begin{itemize}
  \item one-time passwords
  \item smart cards
  \item LDAP servers
  \item biometric systems
  \item \ldots
  \end{itemize}
\end{itemize}


\section{Adding User Accounts with {\fn useradd}}
\label{sec:useradd}

\begin{itemize}
\item Many programs exist for adding users

\item GUI programs:
  \begin{itemize}
  \item {\pgn linuxconf} and
  \item {\pgn userconf}
  \end{itemize}
 
\item one program is standard across many other Unix
  systems: {\pgn useradd}

\item To add the user Chan Hei-man with the user name heiman, and
  unrestricted password age:
\begin{alltt}
$ \textbf{sudo useradd -c "Chan Hei-man" heiman}
\end{alltt}%$

\item To set Chan Hei-man's initial password:
\begin{alltt}
$ \textbf{sudo passwd heiman}
Changing password for user heiman
New UNIX password: 
Retype new UNIX password: 
passwd: all authentication tokens updated successfully
\end{alltt}%$

\item Password is not shown as you type it, of course.
\end{itemize}


\section{What happens when you create a user account?}
\label{sec:what-happens-when-you-create-a-user-account}

\begin{itemize}
\item When you create an account with {\cmdn useradd}, the program
  does a number of things:
  \begin{itemize}
  \item The program identifies the highest used user ID number, and
    adds one to this value as the new user ID number
  \item It does the same with the group numbers
  \item It creates a home directory
  \item It copies the default login scripts and other setup files from
    {\fn /etc/skel}
  \item It changes the ownership of this home directory to the new
    user and group ID numbers
  \item It locks the password and group files, updates them with the
    new user and group entries
  \end{itemize}
\end{itemize}


\section{Local accounts and LDAP accounts}
\label{sec:LDAP-and-local-accounts}

\begin{itemize}
\item You have configured your computer to use LDAP authentication
  \begin{itemize}
  \item All the user account information is stored on an LDAP server
    \begin{itemize}
    \item LDAP = Lightweight Directory Access Protocol
    \end{itemize}
    
  \item All the information normally stored in the {\fn passwd} and
    {\fn group} files is stored in the LDAP server
    
  \item LDAP also provides information used by the \emph{automounter},
    a program running on the client that automatically mounts your
    home directory by NFS when you log in
  \end{itemize}
  \item The automounter manages the directory {\fn /home} all access
    to {\fn /home} is controlled by the automounter

  \item You cannot create local directories in {\fn /home}
    
  \item \ldots so you need to tell {\pgn useradd} to use another
    directory when creating local accounts
\end{itemize}

\section{Configuring {\pgn useradd} to create local accounts}
\label{sec:local-accounts}

\begin{itemize}
\item First create a new directory where your new local users will have
  their home directories:
\begin{alltt}
$ \textbf{sudo mkdir /home2}
\end{alltt}%$

\item Next tell {\pgn useradd} where new home directories should be
  based:
\begin{alltt}
$ \textbf{sudo useradd -D -b /home2}
\end{alltt}%$
  \begin{itemize}
  \item Note that \texttt{-D} sets the new defaults for future use of
    {\pgn useradd}

  \item The option \texttt{-b /home2} selects {\fn /home2} as the
    \textbf{b}ase of all future home directories created using {\pgn useradd}
  \end{itemize}
\end{itemize}

\section{Creating a group}
\label{sec:creating-a-group}

\begin{itemize}
\item The industry standard for creating a new group is {\pgn
    groupadd}.

\item To create the group \texttt{admin}, type:
\begin{alltt}
$ \textbf{sudo groupadd admin}
\end{alltt}%$
\end{itemize}


\section{Adding a user to a secondary group}
\label{sec:adding-user-to-group}

%% \begin{itemize}
%% \item The command {\pgn usermod} can be used to add a user to a {\kwd
%%     secondary} or {\kwd supplementary} group

%% \item A {\kwd secondary group} is a group that a user belongs to,
%%   which is not their primary group.

%% \item Here is an example of adding the user \texttt{heiman} to the
%%   groups \texttt{students} and \texttt{project} (\emph{and remove}
%%   \texttt{heiman} \emph{from any other secondary group}, type:
%% \begin{alltt}
%% $ \textbf{usermod -G students,project heiman}
%% \end{alltt}%$

%% \item It is important to understand that this command will remove
%%   \texttt{heiman} from any other group which is not his primary group.
%% \end{itemize}

%% \subsection{Better: use {\pgn gpasswd}}

\begin{itemize}
\item The command {\pgn gpasswd} can be used to add a user to a {\kwd
    secondary} or {\kwd supplementary} group, and also to remove a
    user from a group.
  
\item A {\kwd secondary group} is a group that a user belongs to,
  which is not their primary group.

\item You can add \texttt{heiman} to the \texttt{admin} group more
  simply with:
\begin{alltt}
$ \textbf{sudo gpasswd -a heiman admin}
\end{alltt}%$

\item Note that this will \emph{not} affect any other group
  memberships \texttt{heiman} already has.



\item Type:
\begin{alltt}
$ \textbf{man gpasswd}
\end{alltt}%$
for more information
\end{itemize}


\section{What groups does this user belong to?}
\begin{itemize}
\item To find out what groups you belong to, type:
\begin{alltt}
$ \textbf{groups}
\end{alltt}%$

\item To find out what groups a user {\uin user} belongs to, type:

\begin{alltt}
$ \textbf{groups user}
\end{alltt}%$

\item The {\cmdn id} command shows information about your groups and
  user id:
\begin{alltt}
$ \textbf{id}\myss
uid=2270(nicku) gid=2270(nicku) groups=2270(nicku),14171(staff)
\end{alltt}%$

\item The {\cmdn id} command is very useful, and has a number of
  options.  See \texttt{man id}
\end{itemize}

\section{Effective group ID and {\cmdn newgrp}}
\label{sec:effectiveGID}

\begin{itemize}
\item When a person logs in, any files they create are normally owned
  by their primary group.

\item A user can change their {\kwd effective GID} to another group
  that they already belong to, using the {\cmdn newgrp} command

\item The effective \acro{GID} is shown on the left when you type {\cmdn
    groups}.
  
\item When you create a file, the group owner is the same as your
  effective \acro{GID}.
\end{itemize}




% \section{\pgn sudo}
% \label{sec:sudo}

% \begin{itemize}
% \item {\pgn sudo} is an \emph{essential} tool for system
%   administrators

% \item It allows you to perform some regular system admin tasks without
%   logging in as root.

% \item It records all actions in the system log, together with the
%   exact user who performed them

% \item To add a user, do this:
% \begin{verbatim}
% $ sudo useradd -c "Full Name" username
% \end{verbatim}%$
% where username is the name you want to add, and ``Full Name'' is their
% full name.

% \item The first time you use {\cmdn sudo}, type your own password.
  
% \item If you use it within the timeout period (by default, 5 minutes)
%   since you last used {\cmdn sudo}, you do not need to type your
%   password.
% \end{itemize}

% \section{{\pgn sudo} Configuration}
% \label{sec:sudo-config}

% \enlargethispage{\baselineskip}
% \begin{itemize}
% \item Type
% \begin{verbatim}
% # visudo
% \end{verbatim}

% \item Refer to Module \ref{cha:intro2vi} for guidance on using the
%   {\pgn vi} text editor.  You will find the `{\cmdn o}' and `{\cmdn i}'
%   commands useful: see section~\vref{sec:insert command}.

% \item Or, if you prefer {\pgn emacs} to {\pgn vi} like I do, then you
%   could type:
% \begin{verbatim}
% # EDITOR=emacs visudo
% \end{verbatim}

% \item Edit the file so that it looks like this, taking care to type it
%   accurately, but put your username instead of mine:
% {\myfs
% \begin{verbatim}
% # sudoers file.
% #
% # This file MUST be edited with the 'visudo' command as root.
% #
% # See the sudoers man page for the details on how to write a sudoers file.
% #

% # Host alias specification

% # User alias specification

% # Cmnd alias specification
% Cmnd_Alias     USER = /usr/sbin/useradd, /usr/sbin/userdel, \
%                       /usr/sbin/usermod, /usr/sbin/groupadd, \
%                       /usr/sbin/groupdel, /usr/sbin/groupmod, \
%                       /usr/bin/passwd

% # User privilege specification
% root    ALL=(ALL) ALL
% nicku   ALL=(root) USER
% \end{verbatim}}

% \item Save it and exit by typing (in {\pgn vi}):
% \begin{verbatim}
% :wq
% \end{verbatim}
% and {\pgn sudo} is now configured.
% \end{itemize}


\section{Directory for a Group Project}
\label{sec:group-directory-permissions}

\begin{itemize}
\item As system administrator, you may need to provide a directory
  that a group of people can use for a project, so that all can read
  and write that directory, but access by others is restricted.

\item Specifications:
  \begin{itemize}
  \item directory name is {\fn /var/project}

  \item members of the group \texttt{admin} are allowed read and write
    access to {\fn /var/project}

  \item other users cannot read or write or change into the directory.
  \end{itemize}

\item Change the ownership of the directory so that it is owned by the
  user \texttt{root} and has group owner \texttt{admin}:
{\myfs
\begin{alltt}
$ \textbf{sudo chown root:admin /var/project}
$ \textbf{ls -ld /var/project}
drwxr-xr-x    2 root     admin        4096 Dec 21 12:27 /var/project
\end{alltt}}

\item Change the permissions of the directory so that the user root
  and the group owners have read, write and execute permission, and
  other users have no access:
{\myfs
\begin{alltt}
$ \textbf{sudo chmod ug=rwx,o= /var/project}
# or sudo chmod 770 /var/project
$ \textbf{ls -ld /var/project}
drwxrwx---    2 root     admin        4096 Dec 21 12:27 /var/project
\end{alltt}}

\item See section~\vref{sec:filesystem-basic-Access-Control-and-UID}
  for more about file permissions and {\cmdn chmod}.
\end{itemize}


\section{File permissions for directories}
\label{sec:directory-permissions}

\begin{itemize}
\item It is easy enough to understand the read, write and execute
  permission when applied to an ordinary file;

\item What about for directories?

\item The {\kwd execute} permission is the permission to use the
  {\cmdn cd} command to change into the directory.

\item The {\kwd read} permission is the right to list the contents of
  the directory with {\cmdn ls}

\item The {\kwd write} permission is the write to change entries in
  the directory

\item What is a \emph{directory entry}?  For each file in the
  directory, there are only two items:
  \begin{itemize}
  \item The file name
  \item The inode number
  \end{itemize}
So the {\kwd write} permission is the right to change either of these.

\item This {\kwd write} permission includes:
  \begin{itemize}
  \item The right to create, delete or rename a file
  \item The right to change the inode number
  \end{itemize}
\end{itemize}


\section{Examples of minimum file permission requirements}
\label{sec:minimum-file-permissions}

\begin{itemize}
\item This table shows examples of minimum file permission
  requirements 
\item It is based on table 2-2 on page 37 of the book \emph{Essential
    System Administration} by \AE leen Frisch, O'Reilly 2002.
  
\item Buy this excellent book!  SysAdmins can't work well without it!

  {\myfs
  \begin{tabular}[t]{@{}>{\ttfamily}lcc@{}}
    \toprule%
    \textnormal{Command} & \multicolumn{2}{c@{}}{minimum access required}\\
    \cmidrule(l){2-3}%
    & on the file & on the directory\\
    \midrule%
    cd /var/project & no file & \texttt{--x}\\
    ls /var/project & \texttt{---} & \texttt{r--}\\
    ls -l /var/project & \texttt{---} & \texttt{r-x} \\
    cat /var/project/user1.txt & \texttt{r--} & \texttt{--x} \\
    echo "hello" >> /var/project/user1.txt & \texttt{-w-} &
    \texttt{--x} \\
    /var/project/binary-program & \texttt{--x} & \texttt{--x} \\
    /var/project/script-program & \texttt{r-x} & \texttt{--x} \\
    rm /var/project/user1.txt & \texttt{---} & \texttt{-wx} \\
    \bottomrule
  \end{tabular}}
\end{itemize}

\section{Set Group ID Directory}
\label{sec:setgid-dir}

\begin{itemize}
\item There are three ``special permissions'' that can apply to a
  file.  You can read about them if you type:
{\myfs
\begin{alltt}
$ \textbf{info chmod}
$ \textbf{info "(coreutils)File permissions"}
\end{alltt}}
See section \vref{sec:info} for more about {\cmdn info}.

\item Here we look at the ``set group id'' (\SGID) permission for
  directories.

\item If this permission is set on a directory, then:
  \begin{itemize}
  \item if a user makes a change to a file or creates a file in that
    directory, the file will have group owner the same as the
    directory.
    
  \item If a user creates a directory in that directory, it too will
    have the Set Group \ID bit set.  As with the file, it will have a
    group owner the same as the group owner of its parent \SGID
    directory.
  \end{itemize}
\end{itemize}

\section{Set Group ID Directory --- Example}
\label{sec:setgid-dir-example}

\begin{itemize}
\item Let's see the result of creating a file in {\fn /var/project}
  both before and after adding this permission:
{\myfs
\begin{alltt}
$ \textbf{ls -ld /var/project}
drwxrwx---    2 root     admin        4096 Jan  2 13:48 project
$ \textbf{touch /var/project/test1}
$ \textbf{ls -l /var/project}
-rw-rw-r--    1 nicku    nicku           0 Jan  2 13:53 test1
\end{alltt}}%$
  Now we add the set group \ID bit to the directory permissions, and
  see the effect:
{\myfs
\begin{alltt}
$ \textbf{sudo chmod g+s /var/project}
$ \textbf{ls -ld /var/project}
drwxrws---    2 root     admin        4096 Jan  2 13:48 project
$ \textbf{touch /var/project/test2}
$ \textbf{ls -l /var/project}
-rw-rw-r--    1 nicku    nicku           0 Jan  2 13:53 test1
-rw-rw-r--    1 nicku    admin           0 Jan  2 13:54 test2
\end{alltt}}

\item when the directory is not \SGID, files I create
  have my primary group ID.

\item when the directory \emph{is} \SGID, files I create
  have the group \ID of the directory.  This allows others in the group
  to read, write and change the files created by any group member.
\end{itemize}


}% end of \mns started at beginning of this file.

\section{User Management Exercises}
\label{sec:manage-users-exercises}

{\normalsize
  \begin{enumerate}
  \item Configure your \texttt{PATH} as described in
  section~\vref{sec:PATH}.  You should already have done that.

\item Configure {\pgn sudo} as discussed in the handout on {\pgn
    sudo}.  Again, you should  already have done that.
%     section~\vref{sec:sudo-config}.

%   \item Also add the commands:
% \begin{verbatim}
% Cmnd_Alias      CHOWN = /bin/chown
% Cmnd_Alias      CHMOD = /bin/chmod
% Cmnd_Alias      MDRD = /bin/mkdir, /bin/rmdir
% Cmnd_Alias      LS = /bin/ls
% \end{verbatim}

% then after your username at the bottom, add these commands so that the
% list looks something like this:
% \begin{verbatim}
% nicku   ALL=(root) USER, CHOWN, CHMOD, MDRD, LS
% \end{verbatim}

%   \item Take care to get the syntax correct; {\pgn visudo} will quickly
%     tell you if there is a mistake.

%   \item Perform all the remaining exercises as your own user account,
%     \emph{not} as root.
%   \end{enumerate}
  
\item Configure the new default base for local home directories, as
  discussed in section~\vref{sec:local-accounts}
  
\item \label{qes:groupadd}\emph{Create four local user accounts, and
    create two additional local groups}, using \texttt{sudo useradd}
  and {\pgn sudo groupadd}.  Set their passwords using {\cmdn sudo
    passwd \usb username}.
  
\item Add two users to one of the groups (make this their
  \emph{secondary} group).  Similarly, add the remaining 2 users to
  the other group (make it their secondary group).  Do \emph{not}
  change the users' effective group ID using the {\cmdn newgrp}
  command in these exercises: simply leave their effective group ID as
  their primary group.

\item Create a directory {\fn /var/project}, using {\cmdn sudo} of course.

\item Set the permissions and ownership as shown in
  \vref{sec:group-directory-permissions}:

\begin{alltt}
$ \textbf{ls -ld /var/project}
drwxrwx---    2 root     admin        4096 Jan  2 13:48 project
\end{alltt}%$
Note: instead of \texttt{admin}, type the name of one of the groups
you made in step~\ref{qes:groupadd}.

\item \label{que:user1}Log in as one of the users who belongs to the
  same group as the one who owns the directory {\fn /var/project} by
  typing:

{\cmdn \$\ su - \uin username}

\item \label{que:createfile}As the user that you logged in as in
  step~\ref{que:user1}, Create a file in the directory {\fn
    /var/project}.
  \begin{enumerate}
  \item What are the permissions on that file?
  \item Which user owns the file?
  \item Which group owns the file?
  \end{enumerate}

  
\item In another window, log in as the \emph{other} user who is
  \emph{also} in the \emph{same} group that owns the directory {\fn
    /var/project}.  Edit the \emph{same file} as you created in
  step~\ref{que:createfile} and save it.  Are you successful?  Why or
  why not?
  
\item In another window, log in as the \emph{other} user who is
  \emph{not} in the group that owns the directory {\fn /var/project}.
  Edit the \emph{same file} as you created in
  step~\ref{que:createfile} and save it.  Are you successful?  Why or
  why not?
  
\item Now set the permissions on the directory to be SGID as shown in
  \vref{sec:setgid-dir}.  Create a second file as the first user, in
  the group that owns the directory.  What are the permissions and
  ownership of the second file?

\item  Can you edit and save the second file as the second user, who
  is also in the same group that owns the directory?  Why
  or why not?

\item  Can you edit and save the second file as a user who
  is also \emph{not} in the same group that owns the directory?  Why
  or why not?  What access rights do you have as a user from a group
  that does not own the directory?

\item Additional exercise: marked by your supervisor on a scale of
  0~to~4.  You have thirty minutes to complete this exercise:

  Requirements:
  \begin{itemize}
  \item you are to create three user accounts and one directory.

  \item two users should have read and write access to the directory,
  and if one user saves a file, the other must be able to edit and
  save the file.
  
  So if these two users are \texttt{user1} and \texttt{user2}, then if
  \texttt{user1} creates a file in the directory, then \texttt{user1}
  and \texttt{user2} should have read \texttt{and} write access
  to that file, but not other users should have write access.
  
\item No other user (including the third you created) should have
  write access to the directory; they should, however, be able to
  change into the directory and list the content of the directory, and
  should be able to read any files created in that directory by the
  first two users.

\item No manual intervention is required by any of the users.  It should
  all just work.%  Hint: look at {\cmdn umask}.
  \end{itemize}
\end{enumerate}

\section{User Management Solutions}
\label{sec:manage-users-solutions}

\includeversion{Solutions}
\excludeversion{noSolutions}

\begin{Solutions}
\begin{enumerate}
\item 
\begin{alltt}
$ \textbf{echo $PATH}
/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/nicku/bin
\end{alltt}%
Oh dear, the directories containing system administrator commands are
not on my \texttt{PATH}\@. Better add them.
\begin{alltt}
$ \textbf{echo PATH=$PATH:/usr/sbin:/sbin >> \(\sim\)/.bash_profile}
$ \textbf{. \(\sim\)/.bash_profile}
$ \textbf{echo $PATH}\small
/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/nicku/bin:/usr/sbin:/sbin
\end{alltt}%$
\item \label{qes:sudo-all-all}Follow the procedures given in the
  handout on {\cmdn sudo}.
  %\vref{sec:sudo-config} and in the question.
  This is how a competent
  senior system administrator will configure {\pgn sudo} for you when
  delegating a system administration task to you.  If you are the
  senior system adminstrator, then you can configure {\pgn sudo}
  simply by adding a line like this:
\begin{verbatim}
nicku   ALL=(ALL) ALL
\end{verbatim}
(substituting your own username instead of nicku, of course).  This
means that user nicku can execute all of the commands as any user
(the user is specified in the parentheses), and can execute any
command using {\pgn sudo} (the program list is given by the last
\texttt{ALL}).

\item
\begin{alltt}
$ \texttt{sudo mkdir /home2}
$ \textbf{sudo useradd -D -b /home2}
\end{alltt}
Then when we add user accounts from now on, the home directories will
go under \texttt{/home2} instead of under \texttt{/home}.  We do this
because the automounter controls access to the directory
\texttt{/home}, and only the home directories for network accounts
can be there.

%  Answer questions 4 and 5 in one go:

\item There are a number of ways of doing this and the next step; I
  will show a few different ways:
\begin{verbatim}
$ sudo groupadd g1
$ sudo groupadd g2
$ sudo useradd u1 -G g1
$ sudo useradd u2 -G g1
$ sudo useradd u3 -G g2
$ sudo useradd u4 -G g2
$ sudo passwd u1
$ sudo passwd u2
$ sudo passwd u3
$ sudo passwd u4
\end{verbatim}
Or you can do it in two steps:
\begin{verbatim}
$ sudo groupadd g1
$ sudo groupadd g2
$ sudo useradd u1
$ sudo useradd u2
$ sudo useradd u3
$ sudo useradd u4
$ sudo passwd u1
$ sudo passwd u2
$ sudo passwd u3
$ sudo passwd u4
$ sudo usermod u1 -G g1
$ sudo usermod u2 -G g1
$ sudo usermod u3 -G g2
$ sudo usermod u4 -G g2
\end{verbatim}
Or, if you have read the {\pgn bash} man page, and want to try some
shell {\cmdn for} loops, you could do it like this:
\begin{verbatim}
$ for g in g1 g2; do sudo groupadd $g; done
$ for u in u1 u2; do sudo useradd -G g1 $u; done
$ for u in u3 u4; do sudo useradd -G g2 $u; done
$ for u in u{1,2,3,4}; do sudo passwd $u; done
\end{verbatim}
{\pgn bash} will expand \texttt{u\{1,2,3,4\}} to \texttt{u1 u2 u3
  u4}: try {\cmdn \$ echo u\{1,2,3,4\}}

\stepcounter{enumi}% Have already answered question 5.

\item {\cmdn \$ \textbf{sudo mkdir /var/project}}

\item {\cmdn \$ \textbf{sudo chown root:g1 /var/project}}
  
  Note that the {\cmdn chown} command has the user, then group owner
  of the file separated by a colon (or a dot).
  
  We can specify the permissions of the file numerically or
  symbolically:

{\cmdn \$ \textbf{sudo chmod 770 /var/project}}

or

{\cmdn \$ \textbf{sudo chmod ug=rwx /var/project}}

\item Open another window (or a new tab in your terminal window), then
  type:

{\cmdn \$ \textbf{su - u1}}

Note the minus sign \texttt{-} here, which means: ``execute the login
scripts of the user.''  Otherwise, many of the environment variables
will remain as they were for your own account.

\item
\begin{alltt}
$ \textbf{cd /var/project}
$ \textbf{echo "I am user 1" > user1.txt}
$ \textbf{ls -l user1.txt}
-rw-rw-r--    1 u1       u1             12 Jan 16 14:45 user1.txt
\end{alltt}%$
\begin{enumerate}
\item The permissions are read and write for the user that owns the
  file (for \texttt{u1}), and for the group owner (the group
  \texttt{u1}), and read for all other users.

\item \texttt{u1}, the user that created it.

\item \texttt{u1}, the effective group ID of the user that created it.
\end{enumerate}

\item Open a new window (or a new tab in your terminal window), and
  type:
\begin{alltt}
$ \textbf{su - u2}
$ \textbf{cd /var/project}
$ \textbf{vi user1.txt}
\end{alltt}%$
  then insert some more text into the file, and try to save with the
  {\pgn vi} command

  {\cmdn :wq}

  As \texttt{u2}, I can change into the directory and open the file in
  an editor, but I cannot save it, unless, in {\cmdn vi}, I type

  {\cmdn :w!}

  This is because \texttt{u2} is not the user \texttt{u1} that owns
  the file, is not a member of the group \texttt{u2} that owns the
  file, so the permissions that apply to \texttt{u2} are those of
  ``other'', i.e., only the read permission.

  Note that user \texttt{u2} has permission to read, write and change
  into the directory {\fn /var/project}, since \texttt{u2} is a member
  of group \texttt{g1}, the group owner of the directory, hence the
  directory permissions that apply to user \texttt{u2} are those of
  the group, i.e., read, write and execute.

\item \label{qes:u3-perms}(Open another window for \texttt{u3} first,
  to save time later.)  As user \texttt{u3}, I do not have permission
  to change into or list the directory {\fn /var/project}.  Even
  though it seems I have read permission on {\fn
    /var/project/user1.txt}, I cannot do this as \texttt{u3}:

  {\cmdn \$ cat /var/project/user1.txt}

  and get anything more than a ``{\sco permission denied}'' message

  Since \texttt{u3} is \emph{not} a member of group \texttt{g1}, the
  group owner of the directory, and is not the user \texttt{root} that
  owns the directory, hence the directory permissions that apply to
  user \texttt{u3} are those of ``other'', i.e., no permissions.  The
  user \texttt{u3} needs to have at least execute permissions on {\fn
    /var/project} before {\cmdn \$ cat /var/project/user1.txt} will
  display the contents of the file.

\item Click on the window where you, the administrator, is logged in,
  and do:
\begin{verbatim}
$ sudo g+s /var/project
\end{verbatim}%$
  and click back on the window for \texttt{u1}, and do:

  {\cmdn \$ echo "I am user 1 back again" > user1-second-try.txt}
  
  The permissions are the same as before.  The user that owns the file
  is \texttt{u1}, the same as for {\fn user1.txt}.  Only the group
  owner of this new file is different: it is \texttt{g1}, the same
  group that owns the directory.

\item I have no trouble to edit and save the file {\fn
    user1-second-try.txt} as user \texttt{u2}.  When I save it, the
  permissions are unchanged, the group owner is still the same as the
  group owner of the directory, but the user that owns the file is now
  \texttt{u2}.  Note that user \texttt{u1} can continue to edit the
  same file {\fn user1-second-try.txt}.

\item As \texttt{u3}, I still have no access rights to the directory
  or the files in it.  The reasons are the same as for
  question~\ref{qes:u3-perms}.

\item This is the same set up as before, execpt that the permission on
  the directory is 775 instead of 770.
  
  \bigskip

  Note that it is possible for the users \texttt{u1} and \texttt{u2}
  to type:
  
  {\cmdn \$ newgrp g1}
  
  to change their effective group ID to \texttt{g1} before they create
  the files in the shared directory.  They can then easily edit each
  other's work.  However, it is better as the system administrator to
  demand less of the users (that takes less of your effort!) and to
  make things easier for them to manage.
  
  These directory sharing systems all depend on each user having their
  own private group to which noone else belongs, and the
  \texttt{umask} being 002 instead of 022 as on other non Red Hat type
  systems.  This is sometimes called the \emph{Red Hat private user
    group scheme}.
\end{enumerate}

\end{Solutions}
\begin{noSolutions}
  We will provide solutions soon.
\end{noSolutions}

\excludeversion{Solutions}
\includeversion{noSolutions}

}% end of normalsize
