Administração de Sistemas (ASIST)

1. Administração de Sistemas(ASIST) TP 2 (English Version) LINUX – Users Management

2. 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

3. 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.

4. “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 . NIS Servers Windows 2003 Server LDAP Servers libnss_ldap.so libnss_nis.so libnss_winbind.so MySQL Server DNS Servers libnss_dns.so libnss_mysql.so libnss_files.so NSS Operating System /etc Queries

5. 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

6. 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).

7. 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_cracklib.so pam_radius.so pam_rootok.so pam_ftp.so pam_winbind.so pam_ldap.so pam_shells.so pam_mysql.so pam_issue.so pam_time.so pam_unix.so pam_mail.so

8. 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.

9. 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: -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 dcredit=0 ucredit=0 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 Authentication Access checking Password change procedure Session management

10. PAM – Some of the most often uses modules

11. 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 create the user’s home, the /etc/skel/ folder is used as a model and all objects in it are copied to the new home. -bash-3.00$ ls -la /etc/skel/ total 32 drwxr-xr-x 3 root root 4096 Out 17 2006 ./ drwxr-xr-x 76 root root 8192 Mai 30 10:20 ../ -rw-r--r-- 1 root root 24 Jun 13 2005 .bash_logout -rw-r--r-- 1 root root 191 Jun 13 2005 .bash_profile -rw-r--r-- 1 root root 124 Jun 13 2005 .bashrc -rw-r--r-- 1 root root 3793 Ago 23 2005 .screenrc 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.

12. 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) 4 2 1 4 2 1 4 2 1 4 2 1 4 2 1 8 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.

13. 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 LANGUAGE HOSTNAME LANG PATH LD_LIBRARY_PATH MANPATH USER TERM 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.

14. 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.

15. 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 fi umask 022 USER=`id -un` LOGNAME=$USER MAIL="/var/spool/mail/$USER" 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 UMASK definition Setting some environment variables Marking variables for export Folder with other scripts to execute on the shell startup.

16. 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.

17. 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.

18. 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.

19. 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: mvw@planets.elm.net, jack@suse.cz

20. 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.