Administração de Sistemas
(ASIST)
TP 2 (English Version)
LINUX – Users Management
1
Users and groups databases
The standard way for Unix to store data about users and groups is on text files,
the file /etc/passwd for users and the file /etc/group for groups. The
/etc/shadow file stores additional users data unavailable in /etc/passwd file.
bash-3.00$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
nobody:x:65534:65534:Nobody:/:/bin/sh
sshd:x:77:77:system user for openssh:/var/empty:/bin/true
www:x:98:98:Gestor WWW:/users/home/www:/usr/bin/tcsh
i977805:x:2176:102:Joaquim Cardoso Morais:/users/home/i977805:/bin/csh
andre:$1$s2b9pyc6$46nIOl8G1fGrymmvsJejG/:1203:98:Andre:/home/andre:/bin/bash
-bash-3.00$ cat /etc/group
root:x:0:
bin:x:1:
nogroup:x:65534:
sshd:x:77:
users:x:100:
inf:x:102:
profs:x:98:
dom_users:x:1003:andre,i977805
2
Local users and groups management
Most current distributions provide a graphical mode user and group
management program which provides most of the basic management functions.
In text mode (console/terminal) there is a set of standard commands in Linux:
useradd ; usermod ; userdel ; groupadd ; groupmod ; groupdel ; chfn ;
chsh ; passwd.
This console commands were developed long ago and have been in use for a
some time so they are very stable and reliable.
The third way is to directly edit the files, this should be done with some caution
to avoid bad formats or any inconsistency with duplicate identifiers.
If users and group data is stored in remote databases, then the management
should be performed in those remote databases, in many most cases its not
possible their local management.
3
“Name Service Switch” (NSS)
The need for central databases with system configuration data (among others, users
and groups databases) lead to the development of alternatives to the local /etc files.
One of the most successful was the Network Information Service (NIS), by SUN,
also known as Yellow Pages.
Name Service Switch (NSS) was developed with the purpose to support several
alternatives currently available. NSS is a modular systems, this means support for new
kinds of databases can by integrated simply by adding a new module .
LDAP
Servers
NIS
Servers
libnss_ldap.so
Windows 2003
Server
libnss_nis.so
libnss_winbind.so
DNS
Servers
MySQL Server
libnss_dns.so
libnss_mysql.so
libnss_files.so
/etc
NSS
Queries
Operating System
4
NSS configuration file “/etc/nsswitch.conf ”
The NSS service configuration is stored in the nsswitch.conf, typically placed in
the /etc folder. Its main role is setting the order by which the databases will be
searched.
Each NSS module may need its own configuration file, for instance the
libnss_ldap.so module uses /etc/ldap.conf or similar file.
bash-3.00$ cat /etc/nsswitch.conf
#
passwd:
files ldap winbind nis
shadow:
files nis
group:
files ldap winbind nis
hosts:
files nis dns winbind
In the sample above, users will be searched in the following order:
1º Local files (/etc/passwd)
2º LDAP servers
3º Windows servers
4º NIS server
The first database where the user is found will be the one used
5
User authentication
Despite its weaknesses the most used authentication mechanism remains to be the
association of a secret phrase (password) to the username.
Who are you?
Prove it!
Due to their secrecy user passwords must be handled with special care. Because
passwords should be stored with the other user account data, supporting different
kinds of users databases means those databases also need to be supported as the
authentication processes.
The answer to this and other challenges in the authentication process was a modular
system to handle the problems around the authentication and access to the system,
the PAM (Pluggable Authentication Modules).
6
Pluggable Authentication Modules (PAM)
In Unix systems the standard way to authenticate a user is checking a digest produced
form the user supplied password, against the digest stored in the user account. Even
when using solid algorithms like MD5 or SHA, it’s wiser to keep those digests away
from public, that’s why digests were moved from /etc/passwd to /etc/shadow file.
Beyond the need to keep he digest secret, the fact the system/server has no access to
the user password (it only knows the digest), makes it impossible to support
challenge-response. The PAM system brought a great flexibility with a wide range of
users databases types and authentication protocols.
As with NSS, PAM is a modular system, each module has a specific function, some
provide access to specific databases, others perform other tasks in the user
authentication process:
pam_listfile.so
pam_radius.so
pam_rootok.so
pam_ftp.so
pam_ldap.so
pam_unix.so
pam_cracklib.so
pam_shells.so
pam_issue.so
pam_mail.so
pam_winbind.so
pam_time.so
pam_mysql.so
7
PAM – module chains
The PAM system follows module chains, these chains set the order in which a module
will take action in the process. The role of the module in the chain can be:
“required” – if successful, if fails also continues to next module in the chain, but at
the end the chain will return fail.
“sufficient” – if successful, without any failure in prior required modules, the chain
will terminate immediately with success. If the module fails an optional fault is
logged and continues to next module in the chain.
“optional” - if successful continues to next module in the chain, if fails also
continues to next module in the chain, but an optional fault is logged.
“binding” - if successful, without any failure in prior modules, the chain will
terminate immediately with success. If fails the chain will terminate immediately with
failure.
“requisite” – if successful continues to next module in the chain, if fails chain will
terminate immediately with failure.
8
PAM - Configuration
PAM system configuration files are normally hold in /etc/pam.d/ folder. There
might be an independent configuration file for each service, in the case shown bellow
there is a generic configuration file included by more specific ones.
PAM configuration
file with the 4 chains:
Authentication
Access checking
Password
change
procedure
Session
management
-bash-3.00$ cat /etc/pam.d/system-auth
#%PAM-1.0
auth
required
pam_env.so
auth
sufficient
pam_unix.so likeauth nullok
auth
sufficient
pam_ldap.so use_first_pass
auth
required
pam_deny.so
account
sufficient
pam_unix.so
account
sufficient
pam_ldap.so use_first_pass
account
required
pam_deny.so
password
required
pam_cracklib.so retry=3 minlen=2
password
sufficient
pam_unix.so nullok use_authtok md5 shadow
password
sufficient
pam_ldap.so
password
required
pam_deny.so
session
optional
pam_mkhomedir.so skel=/etc/skel/ umask=0022
session
required
pam_limits.so
session
required
pam_unix.so
dcredit=0
ucredit=0
9
PAM – Some of the most often uses modules
pam_unix
Can be used in any of the 4 chains, implements the pre-PAM traditional Unix function, it’s a backward
compatibility module.
pam_deny
Can be used in any of the 4 chains, it always returns failure, it’s used for testing and also to close a
chain to ensure it will fail in the end.
pam_env
“auth” and “session” module to setup environment variables as defined in a configuration file like
“/etc/security/pam_env.conf”.
pam_mail
“auth” and “account” module to check if the user has new mail.
pam_ldap
“auth”, “account” and “password” module to interact with LDAP users databases.
pam_issue
pam_motd
pam_nologin
“auth” module that shows a message before the user authentication.
“session” module that shows a message after the user authentication (“message of the day”).
“auth” module, to root always returns success, for other users also returns success, except if the file
/etc/nologin exists, if it does, then the module returns failure.
pam_listfile
Can be used in any of the 4 chains, it returns success or failure depending on the match of some data
(like for instance the username) in file containing a list.
pam_cracklib
“password” module to test the user password quality on the moment he is changing it. The new
password is checked against the system dictionary and some other checking's are also made.
10
User’s work area (HOME)
Depending on the system’s role, users will require a personal and private folder to
permanently hold their files. This folder is known as HOME DIRECTORY or just
HOME.
The HOME location is part of the user account data. In the most common systems
the user should be the owner of his HOME and should have the permission to write
on it, the “700” permissions will allow than and also deny any access to other users.
For services where the “current directory” concept exists, the HOME will be made
the current directory after the login.
Programs that create users may also -bash-3.00$ ls -la /etc/skel/
total 32
create the user’s home, the drwxr-xr-x 3 root root 4096 Out 17 2006 ./
drwxr-xr-x 76 root root 8192 Mai 30 10:20 ../
/etc/skel/ folder is used as a model -rw-r--r-- 1 root root 24 Jun 13 2005 .bash_logout
-rw-r--r-1 root root 191 Jun 13 2005 .bash_profile
and all objects in it are copied to the -rw-r--r-- 1 root root 124 Jun 13 2005 .bashrc
-rw-r--r-1 root root 3793 Ago 23 2005 .screenrc
new home.
drwx-----2 root root 4096 Ago 26 2004 tmp/
After creating/coping the folder the owner ad group must be changed (“chown”
command) and permissions should be also settled with the “chmod” command.
11
User’s work area - permissions
Total privacy in the user’s work area is achieved by removing all permissions to the
group and others, in decimal notation: 700.
Some applications may require
other permissions, for instance,
the “apache” web server requires
the “x” permission in order to
access the user’s personal web
page.
BITS (16)
8 4 2 1
4 2 1
4 2 1
4 2 1
4 2 1
BITS’s decimal value
Object type
Special
permissions
r w x
r w x
r w x
Symbolic notation
OWNER
GROUP
OTHERS
Permissions can easily be changed after creating an object with the “chmod”
command, but the permissions objects are created with can also be controlled by the
UMASK. This is a negation mask, meaning bits on the umask will be forced off
in the object’s permissions.
For instance the 022 UMASK is widely used because it states the bits with decimal value 2
(write permission) for group and others should be turned off.
The UMASK value can be changed with the “umask” command, however the value is
not stored so it must be defined in every session startup.
12
Environment variables
Environment variables are a set of data attached to each running process they can be
used for several purposes, most often they hold information about the system and
running context.
HOME
PATH
MANPATH
LANGUAGE
HOSTNAME
LANG
USER
TERM
LD_LIBRARY_PATH
Environment variables can be marked for exportation (heritage by child processes).
Because of exportation environment variables defined on a initial program will
spread to all processes in the process tree created by it.
Most processes in a Linux system are launched from a shell, most often /bin/sh (or
/bin/bash).
When a shell is started it runs configuration scripts, these scripts can be used to setup
the correct environment, including setting the correct values on environment
variables.
13
SHELL startup files/scripts
Once the shell is the base for launching applications it becomes the perfect place to
setup the environment for those same applications.
Each kind of shell has its own startup files, the standard shell /bin/sh executes
/etc/profile file then the .profile in the user’s home ( ~/.profile).
The standard shell /bin/sh is implemented by the BASH, when called as BASH
(/bin/bash) it uses a more extensive sequence of startup scripts:: /etc/profile ;
~/.bash_profile ; ~/.bash_login ; ~/.profile.
The C shell /bin/csh or /bin/tcsh runs the following sequence of scripts at
startup: /etc/csh.cshrc ; /etc/csh.login ; ~/.cshrc ; ~/.login.
Something to hold is that the user’s area startup files are executed last, that means
they can change what has been done in the system files hold at /etc.
14
The typical /etc/profile file
bash-3.00$ cat /etc/profile
# /etc/profile -*- Mode: shell-script -*# (c) MandrakeSoft
if ! echo ${PATH} |grep -q /usr/X11R6/bin ; then
PATH="$PATH:/usr/X11R6/bin"
fi
if [ "$UID" -ge 500 ] && ! echo ${PATH} |grep -q /usr/games ; then
PATH=$PATH:/usr/games
UMASK definition
fi
umask 022
Setting some environment variables
USER=`id -un`
LOGNAME=$USER
MAIL="/var/spool/mail/$USER"
Marking variables for export
HOSTNAME=`/bin/hostname`
export PATH USER LOGNAME MAIL HOSTNAME
for i in /etc/profile.d/*.sh ; do
if [ -x $i ]; then
. $i
fi
done
unset i
Folder with other scripts to execute on
the shell startup.
15
User and group quotas
Quotas are useful to control and limit the disk space and number of objects each user
or each group is holding in a disk partition.
The goal of quotas is assuring a fair sharing of a limited resource, by imposing limits
we can avoid that someone abuse may compromise the others work.
Quota accounting in handled by the kernel as user processes require operations over
the file system, the kernel detects any change in the use of the file system and
updates the absolute record hold in a file.
The quota control by the kernel works with relative values, it doesn't keep control
over the absolute values of each user, it only updates those values. When the kernel
is told to start controlling quotas it takes by granted that absolute values are updated.
User quotas are about resources owned by each user, group quotas stand for
resources owned by that group.
16
Quota support – mount options
The first to activate quota support is adding the appropriate options the mount
operation of the partition. Those options are “usrquota” and/or “grpquota and
they should be placed in /etc/fstab, this will assure they will be activated every time
the system boots.
Quota support programs check the mount options to know in what partitions there
its supposed to be quota checking active. For instance during the system startup
the “quotaon –a” command is used to activate quota checking by the kernel on all
file systems mounted with quota options.
The “quotaon” command asks the kernel to start controlling quotas on a given
partition (“-a” stands for all partitions with quota options). Before passing the control
to the kernel it is required to have quotas accounting updated.
The “quotaoff” command deactivates quota control by the kernel in a given
partition.
17
Quota support – initial accounting
The kernel checks for usage variation during normal operations over the file system
and with those variations updates the absolute record for the user or group. When
the kernel starts the control the absolute records are supposed to be updated.
The “quotacheck” command scans the whole partition and calculates the space and
files in use by each user and group, the results are stored in the files (a)quota.user
and/or (a)quota.group located at the base of that partition. The “quotacheck”
command is required to run only once, however if the system crashes an the quota
files get corrupted, then “quotacheck” should be run again.
The “quotacheck” command should be run with some precautions, quota control by
the kernel should be off (quotaoff) and no writing should occur during the process.
That is why “quotacheck” tries to mount the partition e read-only mode before
starting.
After running the “quotacheck” command (a)quota.user and/or (a)quota.group
files are updated. Now quotas control can be passed to the kernel, it will take the
mission of keeping the records updated.
18
Quota support – setting the limits
Quota limits must be defined user by user (user quotas) or group by group (group
quotas).
Both for space quota (in 1024 bytes blocks) and number of objects (i-nodes) there
are two limits: a “soft” and a “hard” higher. The “soft” limit can be exceeded, but
only for e period of time known as “grace period”. The “hard” limit can’t be
exceeded.
Any limit defined with the zero value means “no limit”.
Quota limits can be changed using on of two commands: “setquota” and “edquota”,
the last calls a text editor to interact with the user.
-bash-3.00$ /usr/sbin/setquota
setquota: Bad number of arguments.
setquota: Usage:
setquota [-u|-g] [-F quotaformat] <user|group>
<block-softlimit> <block-hardlimit> <inode-softlimit> <inode-hardlimit> -a|<filesystem>...
setquota [-u|-g] [-F quotaformat] <-p protouser|protogroup> <user|group> -a|<filesystem>...
setquota [-u|-g] [-F quotaformat] -b -a|<filesystem>...
setquota [-u|-g] [-F quotaformat] -t <blockgrace> <inodegrace> -a|<filesystem>...
setquota [-u|-g] [-F quotaformat] <user|group> -T <blockgrace> <inodegrace> -a|<filesystem>...
Bugs to: [email protected], [email protected]
19
Quota support – presenting the current status
Each user can view his own quota use by calling the “quota” command, the
administrator may use it to view any user’s quota.
The “repquota” command presents a list of quota status of each user/group in a
given partition.
20