3.5 Local user management

 <  Day Day Up  >  

3.5 Local user management

Local users can be managed either by using the command line or with YaST. Usingthe command line, we issued the following command in order to create a new user:

 # useradd -m gnu01 

The option -m is used in order to create a default home directory. The contents of the default skeleton directory /etc/skel are copied to the newly created home. SuSE adds the new user to the group 100 users by default; there is no separate group created for every new user.

The file /etc/login.defs contains all the defaults for password setting, login retries, umask and path settings. The file /etc/shadow contains encrypted passwords.

Using YaST, we go to "Security Users" (or use the YaST shortcut "users", as shown in Figure 3-2). YaST automatically creates a home directory for a new user.

Figure 3-2. YaST user management


If you want to define user roles (for example printer administrator, database administrator, or user administrator), use user groups. For more special privileges, use sudo , as described in 3.5.2, "Using sudo" on page 108.

3.5.1 User distribution

We discuss centralized user management with LDAP in 3.16, "OpenLDAP implementation" on page 153. However, another alternative for distributing users in the network is Network Information Service (NIS). [9]

[9] Find more information and how-tos for NIS at: http://www.linux-nis.org/nis/

But what if using LDAP and NIS is overkill for our needs? The simplest solution is to manage users locally and distribute the files to other machines.

Using rsync or rdist can be a very fast and reliable solution. The main disadvantage is that users should only change their passwords on the central server, because changing passwords on other nodes will either lead to inconsistencies, or the passwords will be overwritten during the next file distribution.

The main advantage is that there are no compatibility issues for any applications, because all settings are local. Once distributed, this solution stays functional even if the network connection to LDAP or the NIS server fails.

If you want to manage users locally and distribute them to other servers, you need at a minimum to distribute the following files:

  • /etc/passwd

  • /etc/shadow

  • /etc/gshadow

  • /etc/group

If you make any changes to the /etc/skel directory or to /etc/login.defs, you will need to distribute them, as well. In addition, home directories need to be exported through NFS or the automounter, or you can create them locally on each server.

Using rdist for user distribution

The rdist program maintains identical copies of files over multiple hosts . It preserves the owner, group, mode, and mtime of files if possible, and can update programs that are executing. [10]

[10] See man rdist

rdist is called on a master server (management server). It contacts the target nodes through ssh and starts a rdistd daemon on them. The master server and the nodes stats all the files in the configuration file (distfile). If the stat results are different, then files will be copied from the master server to the nodes and the rdistd daemon terminates.

In our case, we create a very simple distfile, shown in Example 3-3, for distribution of user management- related files and the /etc/skel directory (on SuSE).

Example 3-3. /root/distfile example
 HOSTS = ( lpar3 lpar4 lpar5 lpar6 ) FILES = ( /etc/passwd /etc/shadow /etc/group /etc/gshadow /etc/sudoers /etc/resolv.conf) ${FILES} -> ${HOSTS}                 install -savetargets ; 

To avoid being asked for the root password on every LPAR when we run rdist, we enable passwordless key authentication by exchanging ssh keys as described in 3.12.1, "Exchanging ssh keys" on page 144.

Any changes in this file on nodes will be overwritten. In our configuration, rdist will keep one .OLD copy of the overwritten files. If we are going to use rdist to distribute user management-related files, password changes should be only allowed on the management server. We run the rdist command on our management server, as shown in Example 3-4. The option -P is followed by the complete path of the ssh command:

Example 3-4. Running the rdist command
 # rdist -v -P /usr/bin/ssh lpar3: updating host lpar3 lpar3: /etc/passwd: need to install lpar3: /etc/gshadow: need to update lpar3: /etc/sudoers: need to install lpar3: /etc/resolv.conf: need to update lpar3: updating of lpar3 finished 

We can run rdist as a cron job, or run it every time we make changes to any of the files in our distribution list.

For more information, see the homepage of the rdist project at:


A useful introduction to rdist can be found at:


3.5.2 Using sudo

The sudoprogram allows normal users to execute predefined tasks which usually can only be executed by root. It can be used for improving overall system security; administration task delegation with sudo does not mean giving the root password away.

sudo is a setuid binary that is owned by root and can be executed by other users:

 # ls -al /usr/bin/sudo -rwsr-xr-x    1 root    root     95296 Nov  11  2002 /usr/bin/sudo 

If users run sudo , they run it with root rights, or with the rights of a specified target user. The configuration for sudo is done in the /etc/sudoers file. Do not edit this file manually; instead, use visudo to edit it, as shown in Example 3-5 on page 109.

Making user root equivalent

In our first example, we use a very simple scenario: granting all rights to a user we trust. This is more secure than giving away a root password.

Example 3-5. Granting all root rights to user
 #  visudo  # 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 # Defaults specification # User privilege specification root            ALL=(ALL) ALL  brockhaus       ALL=(ALL) ALL  # Uncomment to allow people in group wheel to run all commands # %wheel        ALL=(ALL)       ALL # Same thing without a password # %wheel        ALL=(ALL)       NOPASSWD: ALL # Samples # %users ALL=/sbin/mount /cdrom,/sbin/umount /cdrom # %users localhost=/sbin/shutdown -h now "/etc/sudoers.tmp" 29L, 605C                    17,6-16     All 

We add one line:

  brockhaus     ALL=(ALL) ALL  

We write and quit the visudo program with wq.

Now we can log in as user brockhaus and test our new granted rights, as shown in Example 3-6 on page 110. Note that user does not gets root path settings automatically, so we need to provide the full path to the command.

Example 3-6. Using sudo
 brockhaus@p630sles:~> sudo /sbin/ifconfig eth0 We trust you have received the usual lecture from the local System Administrator. It usually boils down to these two things:         #1) Respect the privacy of others.         #2) Think before you type. Password: eth0      Link encap:Ethernet HWaddr 00:02:55:4F:60:8A           inet addr: Bcast: Mask:           inet6 addr: fe80::202:55ff:fe4f:608a/64 Scope:Link           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:5646864 errors:318 dropped:0 overruns:0 frame:318           TX packets:8033920 errors:171 dropped:0 overruns:1 carrier:171           collisions:824271 txqueuelen:100           RX bytes:3259464842 (3108.4 Mb)  TX bytes:8050769484 (7677.8 Mb)           Interrupt:101 Base address:0xec00 Memory:88030000-88030038 

If we look at /var/log/messages, we see the following entry:

 Nov 10 20:25:18 p630sles sudo: brockhau : TTY=pts/2 ; PWD=/home/brockhaus ; USER=root ; COMMAND=/sbin/ifconfig eth0 

The first time this user issues a sudo something command, he will be asked for a password (his own password, not root's). If he uses sudo again during the next 5 minutes (which is the default, and can be changed in the sudoers file), he will not be asked for the password.

Even so, every time the user needs to issue a command with root rights, the user will need to use sudo in front. .

In our case, we first change the default 5-minute password timeout to zero (0) in order force users to enter the password each time they use sudo. We also add the following line:

 Defaults     timestamp_timeout=0 

If we set timeout to -1, it will never expire, not even if the user logs out. If we use the following setting, then it will only apply to user brockhaus:

 Defaults:brockhaus timestamp_timeout=0 


Experienced Linux administrators never login or work as root. Use sudo !

Delegating tasks

In our second example, we allow a group of database administrators DBADM to kill database processes, and a group of user administrators USRADM to add and delete users. We change the default policy for database administrators, so they do not need to supply a password when issuing the sudo command.

The result is equivalent to defining user roles in some other UNIX systems. In Example 3-7, we use variables in order to make our sudoer's file easy extensible.

Example 3-7. Delegating tasks with sudo
 # # This file MUST be edited with the 'visudo' command as root. # # User alias specification User_Alias      DBADMINS = marju, mathias User_Alias      USRADMINS = karla, pablo # Defaults specification Defaults        timestamp_timeout=0 Defaults:DBADMINS timestamp_timeout=3 # Run as alias specification Runas_Alias     DB = db2, dasusr1 Runas_Alias     OP = root # Cmnd alias specification Cmnd_Alias      KILL=/bin/kill Cmnd_Alias      USRM=/usr/sbin/useradd, /usr/sbin/userdel, /usr/bin/chage # User privilege specification root            ALL=(ALL) ALL brockhaus       ALL=(ALL) ALL DBADMINS        ALL=(DB) NOPASSWD: KILL USRADMINS       ALL=(root) USRM 

Now we can login as user marju and use the sudo -l command to see what rights we are granted, as shown in Example 3-8

Example 3-8. sudo -l
 marju@p630sles:/root> sudo -l User marju may run the following commands on this host:     (db2, dasusr1) /bin/kill 

As you see, we can use the kill command to kill jobs running with a db2 or dasusr1 id, as shown in Example 3-9. We do not need to provide any password, because we used the NOPASSWD option in /etc/sudoers.

Example 3-9. Using sudo as user dasusr1
 marju@p630sles:/tmp> ps auxwwgrep db2 dasusr1  16244  0.0  0.2 21932 4312 ?        S     23:24    0:00 /home/dasusr1/das/adm/db2dasrrm marju@p630sles:/tmp> sudo -u dasusr1 kill -9 16245 marju@p630sles:/tmp> 

More information on sudo and a more sophisticated example file can be found on the sudo mainpage at:


You can also see the available parameters by issuing the sudo -L command as root. The command sudo -V issued as root will also show the version and which settings are in effect.

Using sudo for task delegation can also be achieved by allowing some users to execute all commands in, for example, the /usr/local/admin directory, and then putting the commands we want delegate in this directory.


Use the ALL=(ALL) ALL option only for yourself or someone you really trust. This user will always be able to become root by using su, start, or span root shell in vi mode.

Keeping the security issues in mind when using sudo is better than giving the root password away or working as root. Using sudo prevents commands from being executed as root by accident ; every time you want to run something as root, you need to place sudo in front of the command and provide your password.

With sudo, if the root password needs to be changed, you do not need to inform all other administrators. The sudo logging allows you to determine who has issued which command, and when they issued it. Additional security can be achieved by using remote logging on another server.

 <  Day Day Up  >  

Quintero - Deploying Linux on IBM E-Server Pseries Clusters
Quintero - Deploying Linux on IBM E-Server Pseries Clusters
Year: 2003
Pages: 108

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net