UNIX Unleashed, System Administrator's Edition
by David Gumkowski and John Semencar
While performing user administration you will call upon all of your skills in virtually every area of system management. Whether it is keeping disks as empty as possible, finding system bottlenecks, answering questions, or adding new users, your job revolves almost totally around and for the machine's users. Those users are much like the fans of a baseball game to your rendition of the umpire: You have done a good job if you are unnoticed. Though easy to forget in a harried environment, learning and interacting with system esoterica only can happen because the users are at least indirectly paying the freight.
This chapter deals with operations strictly limited to the administration of user ids. It will refer to adding, removing, modifying, moving, keeping track of, checking, and limiting users. This section describes special ids and user id environments.
Logically enough, user administration begins when adding users to a new machine. Functionally, there are a variety of ways to accomplish this task. Each of the methods involves adding information to the password file, /etc/passwd. The /etc/group file is another file that requires attention as are miscellaneous files such as system shell startup files and the system mail alias file.
The format of /etc/passwd is consistent among most flavors of Unix. This file contains the following colon-separated entries:
username:pswd:uid:gid:uid comments:directory:shell
On some BSD type systems, the file contains slightly different colon-separated entries:
username:pswd:uid:gid:user class:pswd change:acct expiration:uid comments:directory:shell
The username is what the user types in at the Unix login: prompt. Usually, the field's makeup is eight or less alphanumeric characters with the alphabetic characters in lower case. It should be unique. This field should not contain colons because the colon is used as the field delimiter. For best compatibility, this field should not contain dots and should not begin with a hyphen or a plus sign.
The pswd field is a password entry and can have many different forms. The entry can be blank, indicating that there is no password required for login. The position can contain up to 13 characters that are the encrypted version of the password for the user. The location can contain a character not in the following set { . / 0-9 A-Z a-z } connoting that the username is valid but cannot be logged into. For example an "*" is not in this set. If it is used then the username is a valid account but cannot be logged into.
Additionally, under IRIX and HP-UX, the password entry can contain a comma followed by one or two characters.
The characters (in order) are: . / 0-9 A-Z a-z. The "." character is equated to the number zero and "z" is equated to 63. References made to characters using their numeric value are common. The characters indicate the number of weeks the password is valid and the number of weeks that must expire before a change is allowed to the password, respectively. If the former is zero (dot), the user must change the password at the next login attempt. Though generally frowned upon by security conscience individuals, if the latter is greater than the former, only the superuser can change the password.
TIP: If the system has no built in check for user base password selections, Alec Muffett's Crack utility can assist you in that endeavor."
The uid or user id is simply a unique numerical user value for the username. Normally, this value is a positive number up to 65535, although some systems can handle nonrecommended double precision user id numbers. If this is nonunique, all usernames with the same user id look like a single (usually the first) username with this user id. Some user ids are reserved or special. They include:
| 0: | The superuser |
| 1-10: | Daemons and pseudo users |
| 11-99: | System, reserved and "famous" users |
| 100+: | Normal users |
| 60001: | "nobody" (occasionally 32000 or 65534) |
| 60002: | "noaccess" (occasionally 32001) |
The gid or group id is a numerical default group id for the username. This number corresponds to an entry in the /etc/group file. This file will be described later.
The uid comments field is historically known as GECOS, or GCOS, information for the operating system it originated from. For a generic finger command to accurately display this information, it should contain the user's real name, company or office number, office phone number, and home telephone number separated by commas. Not all entries need to be specified, although placeholders must be kept if trying to keep the general GECOS syntax. For example, Homer User,,,800-IAM-HOME would show entries for the user's real name and the user's home telephone number. The real user name is also displayed by the mail system as part of the outgoing mail headers.
The directory field is commonly known as a username's home directory or initial working directory. Basically, it is the directory the user is placed in after being logged in by the system but before the user's personal startup files are executed.
The shell field is the command interpreter or program that the username is placed in after logging in. Among the many shells are: sh (Bourne), ksh (Korn), csh , tcsh (TENEX/TOPS-20 type C), BASH (Bourne Again Shell). If not specified, the default shell is the Bourne shell. Note that this entry does not have to be a shell; it can be a program that locks the username into a captive application. For this field to be valid, some systems require this entry to be present in a shell validation file.
The class field is unused but is for specifying a class of user attributes for the username.
The pswd change field indicates how soon a password must be changed. It is the number of seconds since the epoch (Jan 1 1970 @ 00:00). If omitted, no forced change of the password occurs.
The acct expiration field is the number of seconds since the epoch until the account will expire. If left blank, account expiration is not enforced for the username.
Additionally, if Network Information Service (NIS) / Yellow Pages (YP) is installed and running, the password file can include other types of entries. The additional username field entries include:
| + | all YP entries should be included |
| +username | include the explicit username from YP |
| -username | exclude the explicit username from YP |
| +@netgroup | include all usernames from YP from the desired group |
| -@netgroup | exclude all usernames from YP from the desired group |
Generally, within such entries, if the uid, gid, uid comments, directory, or shell fields are specified, they supplant the value that YP sends for that field. Also, be aware that these entries are taken in order, so the first occurrence, not the last occurrence, dictates what is going to happen. For example:
root:x:0:0:Superuser:/: daemon:*:1:5::/:/sbin/sh bin:*:2:2::/usr/bin:/sbin/sh sys:*:3:3::/: adm:*:4:4::/var/adm:/sbin/sh uucp:*:5:3::/var/spool/uucppublic:/usr/lbin/uucp/uucico lp:*:9:7::/var/spool/lp:/sbin/sh nuucp:*:11:11::/var/spool/uucppublic:/usr/lbin/uucp/uucico hpdb:*:27:1:ALLBASE:/:/sbin/sh nobody:*:-2:60001::/: dave:x:100:10:Dave G,13,x3911,unlisted:/usr1/dave:/bin/tcsh charlene:x:101:10:Charlene G,14,x1800,unlisted:/usr1/charlene:/bin/tcsh john:x:102:60:John S,2,555-1234,x1400:/usr2/john:/bin/ksh georgia:x:103:60:Georgia S,11,x143,x143:/usr2/georgia:/bin/csh -steve:::::: +@friends:::20::: +wayne::102:::/usr3/wayne:/bin/sh
Username steve is always excluded, even if it occurs within the netgroup friends. All friends are included with the noted exception. Every friends included is placed into the 20 group by default. YP wayne is included. All of his fields, except the group id and user id comment fields, are overridden with the specified information. Notice in our sample that the letter x in the pswd field was substituted for the actual encrypted password for this publication. The character * in the pswd field is shown as found for these nonlogin psuedo users. For a further description of psuedo users, go to the end of the "Adding New Users" section.
Since /etc/passwd is usually globally readable, security conscientious sites normally use a shadow password scheme that is available under most Unix operating systems. Ultimately, this redirects the encrypted passwords to another restricted read file that may or may not contain other information. This scheme is employed because average machines today can crack user passwords readily if the user's choice is bad. Bad choices include any dictionary word, the login name, no password, or any information included in the user id comment field. The schemes used for shadow password files vary considerably among the various UNIX variants.
For example, IRIX and Solaris systems have a file named /etc/shadow that is generated by running the command pwconv that includes the following:
username:pswd:lastchg:min:max:warn:inactive:expire:flag
The username is a copy of the username from the /etc/passwd file.
The pswd field contains either the 13-character encrypted password; ) null, indicating that no password is needed for login; or a string containing a character not from the following set--{ . / 0-9 A-Z a-z}. If the password contains a character not from the encryption set, the username cannot be logged into. Normally, system administrators would use * or *LK* for the entry.
The lastchg field is the number of days from the epoch that the password was last changed.
The min field is the minimum number of days to elapse between a successful password change and another change.
The max field is the maximum number of days that the password will be valid.
The warn field contains the number of days before password expiration that the user will begin to get warnings that the password is about to expire.
The inactive field is the number of days that the username can remain inactive before not being allowed to log in.
The expire field is an absolute number of days specification. When used, this specifies when a username will no longer be considered valid to log into.
The flag field is currently unused.
HP-UX has adopted another scheme for shadowing the password file on a trusted system. Each username has a file named /tcb/files/auth/first letter/username where first letter is the beginning letter of the username, and username is the login name for the user. For example, /tcb/files/auth/b/buster would exist for the username buster. This file contains information that is termcap in appearance and at last count, there were 32 possible options contained within this file that deal with user security. A list of field names and their possible values can be found in the man page for prpwd(4). In general, the file holds:
The username and user id mirrored from the password file.
The encrypted password for the username, if any.
The names of: The owner of the account. The last account to change the password on this account if it was not the account itself. The last successful and unsuccessful login attempt terminal name or host name.
The times indicating: The number of seconds allowed between successful password changes. When the password expires (next login will require the user change the password). When the lifetime of the password expires (only the sysadmin can reallow login). The last time a successful and unsuccessful password change or attempt was made. When the account expires (an absolute-lifetime offsets from a password change). The maximum time allowed between logins. How long before password expiration that a user should be notified. The time of day logins for the account are valid. The last time a successful and unsuccessful login entry or attempt was made.
Flags showing: If the username is allowed to boot the system. If audits occur for the username. If the user can select the account's password or must use a system generated one. If the user can have the system generate a password for the account. Whether a chosen password undergoes a check for being too easily guessed. If the account can have no (null) password. If the user can generate "random" characters and letters for a password. If the account is administratively locked.
Numbers specifying: An audit id for the account. The maximum length a password can be. An additional random number an account must specify to a password if the system administrator reset the password. The count of unsuccessful logins until the next successful one. The maximum consecutive unsuccessful login attempts allowed before the account is locked.
Berkeley-type systems have yet another type of shadowing system that uses the files /etc/master.passwd or /etc/spwd.db.
Another file referred to previously that comes into play is /etc/group. It is part of the general protection scheme employed by Unix: user, group, and other permissions on files. The colon-separated template for the file appears as:
group_name:password:group_id:list
The group_name field contains the textual name of the group.
The password field is a placeholder for an encrypted password for the group. If null, no password is required.
The group_id field contains a unique numerical value for the group.
The list field contains a comma-separated list of users who belong to this group. Users need not be listed in groups that are specified for their username in /etc/passwd. A sample /etc/group file follows.
root::0:root
other::1:root,hpdb
bin::2:root,bin
sys::3:root,uucp
adm::4:root,adm
daemon::5:root,daemon
mail::6:root
lp::7:root,lp
tty::10:
nuucp::11:nuucp
users::20:root,dave,charlene,john,georgia,operator,steve,judy,wayne,jamie
nogroup:*:-2:
systech::110:dave,disdb,diskf,disjs,dispm,diskj
dba::201:oracle,john,kathy,pete
psdev::202:ps001,ps002,ps101
hrdev::203:hrprw,hrpps,hrpsl,hrpla,consult1,consult3
fsdev::209:glpmk,glpsf,consult2
fsftp::222:glpmk,glpsf,glpjh
If Network Information Service/Yellow Pages is enabled, this file, like /etc/passwd, can contain entries beginning with a minus or plus sign to exclude or include (respectively) group information from NIS/YP.
A third file that user administration deals with is the system mail alias file. Depending on the UNIX version you are running, this can be located at: /etc/aliases, /usr/sbin/aliases, or /etc/mail/aliases. Users who want a mail address longer than an 8-character username can be satisfied here by creating an alias for themselves. For example, fred-flinstone: flinston would redirect any mail addressed to fred-flinstone on the host machine to the username flinston. Also a group of users occasionally request global mailing lists created for them and this is where you would satisfy their need. After you modify this file, remember to run newaliases for the changes to take effect.
You should be aware of a couple of other files that affect user login administration. These system shell startup up files are invoked before control is turned over to the username's personal startup (dot) files. You can customize an operating environment for users by editing /etc/profile (SYSV sh/ksh users) or by editing /etc/csh.login, /etc/login, or /etc/stdlogin (SYS V csh/tcsh users). In these files, you can customize the default file permissions employed by users when creating files. By setting a umask for them, you can add elements to the default path to include local utilities in /usr/local, or you can add helpful alias or environment variables. Generally, it is a good idea to keep things uncluttered in these files because knowledgeable users customize their own environments. Most systems give a template, or model, to be placed in the user's home directory. HP-UX administrators can find them in the /etc/skel directory. An example of a ksh user's .profile follows:
# Set up the terminal:
if [ "$TERM" = "" ]
then
eval ' tset -s -Q -m ':?hp' '
else
eval ' tset -s -Q '
fi
stty erase "^H" kill "^U" intr "^C" eof "^D"
stty hupcl ixon ixoff
tabs
# Set up the search paths:
PATH=$PATH:/usr/local/bin:$HOME/scripts.d/local:.
# Set up the shell environment:
set -u
trap "echo 'logout'" 0
# Set up the shell variables:
export VISUAL=vi
# Save PATH:
ENVPATH=$PATH
export ENVPATH
ORACLE_TERM=vt100
export ORACLE_TERM
# Set ENV:
ENV=/usr/contrib/bin/oracle_fun
export ENV
# Set user aliases:
alias rm="rm -i" # -- commonly practiced
Berkeley mail users' mail options can be customized globally in the mail start up file: /usr/lib/Mail.rc, /usr/share/lib/mailx.rc, /etc/mail.rc, /etc/mail/mail.rc, or /etc/mail/Mail.rc, depending on your UNIX variant. For example, you could force paging of mail longer than a page by inserting set crt in the mail start up file. Or if you wanted all mail to have a certain type of header line clipped you could ignore Message-Id. Again, though, it is best to keep this simple and let users customize their own mail environment in their .mailrc file.
As seen in the description of the shadow password systems, security among UNIX operating systems is not very standard, so to fully understand what other files can be tweaked dealing with user logins, the chapter one login manual page should be read. For example, on HP-UX you can restrict from what terminal a root login can occur by editing /etc/securetty. On IRIX, /etc/default/login has multiple changeable options such as whether null passwords are acceptible, how many unsuccessful login attempts can be made before disconnecting the line, and if all logins should be logged or if just login failures should be recorded. It is in this file that root logins can be restricted.
Every flavor of UNIX contains password file entries for several psuedo users. Their entries are not to be edited. These nonlogin users are required to satisfy any ownership issues by their corresponding processes. The following list displays the most common.
| daemon | Used by system server processes |
| bin | Owns executable user command files |
| sys | Owns system files |
| adm | Owns accounting files |
| uucp | Used by UUCP |
| lp | Used by lp or lpd subsystems |
| nobody | Used by NFS |
There are more standard psuedo users such as audit, cron, mail, new and usenet. They all are required by their associated processes and own their related files.
To generate, modify, and delete entries in the password and group files is very dependent upon which operating system you use. The basic ways include editing the password file directly, using a command line instruction, or using a graphical tool to insert the entry for you. With benefits, such as templates and point and click features, graphical tools used for user administration are well in use. In the IRIX Toolchest you can find User Manager, a graphical tool that is valued by those who use it.
The HP-UX system administration tool of choice is SAM, in its graphical or character-based mode.
Some command line and graphical tools for selected operating systems are:
| HP-UX | useradd, userdel, and usermod, vipw, or SAM |
| Solaris | useradd, userdel, and usermod or admintool |
| FreeBSD | adduser and rmuser or vipw |
| OpenBSD | adduser or vipw |
| IRIX | User Manager (cpeople) |
| Linux | vipw |
The command line instruction constructs are:
useradd [-c uid comment] [-d dir] [-e expire] [-f inactive] [-g gid]
Also, useradd can set default values for: base dir, expire, inactive, gid, skel_dir, and shell.
adduser [-batch username [gid,[gid...]] [uid comment] [password]] OR adduser
The adduser command with no parameters runs interactively. This command also can set other defaults that will: 1. cause users to have login or profile information copied into their home directory, 2. set new users into a default group, 3. define home partitions for new users, 4. issue a welcoming message to new users, 5. set a default shell for new users, and 6. choose new user ids from a select group of numbers.
userdel [-r] username rmuser username usermod [-c uid comment] [-d dir [-m]] [-e expire] [-f inactive]
In each of the preceding commands
username is the user's login name. This is the only nonoptional parameter in any command.
uid comment is what will be stored in the user id comment (GECOS) field.
dir is the user initial or home directory.
expire is an absolute date when the username ceases valid logins.
inactive is the number of inactive continuous days before the username is locked.
gid is a group id or group name that the username belongs to.
new_username is a replacement name for an existing username.
shell is the username's initial shell.
skel_dir is a directory containing files to copy to the newly created home directory.
uid is the unique user identifier for the username.
-m indicates create the home directory (add) or move current home directory files to the new home directory (mod).
-o allows the user id to be nonunique and still have the command succeed.
-g selects the primary group for the username.
-G selects secondary groups for the username.
-r commands that the username's home directory be removed.
If the home directory of a username is altered, the previous initial directory files must be moved to the new directory. To move a user directory, issue the command:
cd /old_dir; tar -cf - . | (cd /new_dir; tar -xpf -)
Verify the result and then remove old_dir. If the user base is not entirely knowledgeable, look for old_dir in existing files and change them to new_dir for the user. The system can locate any entries by:
find /new_dir -exec grep -l old_dir {} \;
For any entries that find locates, change the entry to new_dir or, when appropriate, change the absolute path name to the more generic $HOME variable. Pay particular attention to the start up (dot) files contained within a user's home directory because errors in that class of file will surely get the attention of a user quickly.
Common dot files include:
| .login | Csh and tcsh-executed during login after the system login processing occurs. |
| .cshrc | Csh-executed when spawning new subshells. |
| .tcshrc | Tcsh-executed when spawning new subshells. |
| .profile | Sh or ksh-executed during login after the system login processing occurs. |
| .kshrc | Ksh-executed when forking new subshells. |
| .bashrc | Bash-executed when forking new subshells. |
| .history | Contains the last set of shell instructions executed. |
| .rhosts | Remote host/username lists that are trusted. Rlogin, rexec, rsh/remsh,Éuse this file to allow login, file access, and command processing without need of password. |
| .netrc | Used by the FTP auto-login process. |
| .forward | Allows the mailer to redirect mail to other addresses, files, or program processors. |
| .mailrc | A start-up file for mail that allows setting mailer options or aliases. |
| .exrc | A start-up file for ex or vi that allows setting specific editor options. |
| .xinitrc | A start-up file for X windowing. |
| .xsession | Another start-up file for X windowing. |
| .xdefault | Yet another start-up file for X windowing. |
When removing usernames from the password file you must locate all of the user's files to delete them. Find once again can do this chore for you.
find / -user username
searches out all of the files belonging to username. To be safe, you might want to back the files up before you delete them. To ferret out and delete within a single command is to carry out the subsequent command:
find / -user username -exec rm {} \;
After purging the username's files, the group file and system mail alias file(s) should be modified by removing the username from them. Newaliases should be run to update the alias database.
Occasionally, user administration functions as a detective because, among other things, the machine becomes overtaxed, security is breached, or statistical information is requested. In cases such as these, UNIX provides tools to gather information about users in general or one user in particular.
The first class of instructions tell you what is happening now. These commands give an indication if anyone is gathering more than their fair share of resources. In addition, they should be used to avoid potential performance problems by justifying the need for more CPU, memory, or disk resources to accommodate the growing needs of your user community.
uptime shows the current time, the number of days the machine has been up, the number of users logged into the system, and the system load average during the past 1, 5, and 15 minutes. It is a somewhat nebulous description of what actually goes into the load average, but it is useful for making comparisons to previous attempts and gives indications if any user is monopolizing the machine's resources.
w gives the uptime information and indicates who is on now, what terminal port they are using, the name of the host the username logged in from, when the username logged in, how long they have been idle, the aggregate CPU time of all processes on that terminal port (JCPU), the CPU time of the active process listed in the next field (PCPU), and what command they are currently running. The idle time gives a good indication of who may be good candidates for being logged out.
ps -ef (SYS V) or ps -ax (Berkeley) gives a lot of information about all running system processes. Pay attention to the time column because this is the cumulative process execution time for the listed process. Any large number is suspect for running amok especially if the parent process id is 1. Possibly you may use kill -9 out_of_control_process_id to tax the system less. If the procedure should not be killed, then possibly you might use the renice command to settle things a bit. renice +10 offending_process_id improves other user process responses. The second parameter (+10) corresponds to a sliding scale from -20 to +20 where -20 would get the most time slices and +20 gets the least.
top gives a ps like output that is updated constantly. In particular, the % cpu and time columns can identify users who are exploiting the system a bit too much. The size parameter, indicating the process size in pages, can identify users who may be causing memory-to-disk swapping to occur too often. Possibly this information shows that the system needs more memory.
fuser can indicate who is tying up a file resource. Running fuser -u filename lists all the usernames and processes that currently use the specified filename. Either the user can be asked to stop tying up the resource, or the offending process can be killed. If a file system is the resource being tied up rather than a file, fuser -cku filesystem_name kills each task controlling a file residing on the file system. Once the command completes, the file system could be umounted.
[B]df in concert with du gives insight into disk overuse. [B]df gives a summary of how full each disk is. For overly full file systems, du -s /filesystem/* displays a grand total of used blocks for each component directory on the file system. You can continue chaining down the largest identified directories until finding something that can be moved, archived, or eliminated. Using find with its size parameter could automate the same result.
GlancePlus is a graphical realtime performance diagnostic tool offered by Hewlett Packard for their HP-UX systems. It may be invoked in its graphical mode via the gpm command. Glance, the character-based component, may be invoked by the command glance. Combining the features of many of the conventional Unix tools described above, system administrators are able to analyze system resources and isolate performance bottlenecks.
When first initiated, GlancePlus displays the Global or Process Summary screens. If you find the memory utilization graph consistently peaking, then press the F2, F3, or F4 keys to drill down and call up detail screens to identify the processes and users in question. Detail screens are available to monitor many system resources such as CPU, memory, swap, disk i/o, nfs, lan and more. Further information is obtained from the Individual Process screens.
Detail is plentiful, and the ease of use is much appreciated. GlancePlus and its component Glance are valuable tools for system troubleshooting and should be utilized by anyone responsible for such.
The next set of utilities and procedures describe a user usage history. First, many network utilities can be placed into verbose modes. For example, fingerd, ftpd, tftpd, and rshd accept a -l or -L option that cause them to relate connection information to a system log file. Normally, adding these options is handled by modifying the program call statements in the inetd configuration file that usually resides at /etc/inetd.conf and then restarting inetd with the following command: killall -HUP inetd. The file can further be modified in conjunction with an add-on package known as tcp_wrappers by Wietse Venema. The package is a port monitor and possibly a proactive limiting daemon depending on how it is configured. In any case, you are better able to determine and restrict your user base network usage.
Small changes to the syslogd configuration file (usually located at /etc/syslog.conf) can cause expression of more information. For example, if the line doesn't already exist, you can add
mail.debug /some_legal_directory/syslog
as the last line of the configuration file. Then have syslogd reread this modified file by executing:
kill -HUP syslogd_process_id
This directs mail to, from, and deferred messages to be placed in a mail queue log file, /some_legal_directory/syslog. This allows better understanding and manipulation of mail so your user's needs can be met.
Another historical tool is the last utility that shows which users are logging on from where and for how long. This tool usually is used in conjunction with acctcom or lastcomm. Acctcom and lastcomm identify system usage by username and tty port. They give administrators insight into what the system is being used for and how much CPU time and memory is being spent on which user tasks. The output indicates when your system is busiest and why it is busy. For these utilities to function, system accounting needs to be turned on and adequate space open for raw accounting files to appear and grow. To better understand how accounting functions work and what needs to be turned on or run, refer to the manual pages for accton and sa for Berkeley systems, and acct and runacct for SYS V systems. Nightly, these data files can be manipulated into human readable logs showing disk usage, cpu usage, memory usage, line printer usage, connection statistics, and command statistics. Again, this permits easier understanding of who is using the system's resources. The process also lets the powers that be charge the users for their resource usage.
Monitoring also extends into the realm of protecting the users from themselves. Correcting system vulnerabilities in general and fixing user's self-made problems in particular are user administration duties. The find utility is particularly helpful in this effort. In most instances, users should not have globally writable directories and possibly not have globablly readable ones either to maintain some semblance of security.
find /user_directory_home /( -perm -o=w -o -perm -o=r /) -type d
locates any globally readable or writable directory. If the command locates many of these directories, you should check the default umask that users receive when logging in. Possibly a umask of 077 is in order. User's .rhosts and .netrc files should not be readable or writable either as they aid attackers.
find /user_directory_home /( -name .rhosts -o -name .netrc \)
finds all globally readable .rhosts and .netrc files. Especially in user directories, there should be very few unknown set uid (SUID) programs on the system, which would ultimately compromise every user and file and the system.
find / -perm -u=s
generates a list of all SUID programs on the system. Adding the -user root parameter on the command lists all root privileged SUID files, so you can verify that all such files are where they are expected to be. Dan Farmer's COPS add-on package can be ftp'd from the network and configured to make checks such as the previous as well as more intense security queries.
The best way to protect users from themselves is to back up their files nightly. Depending on how much information needs to be backed up, a good strategy is to do an incremental dump nightly and full dump weekly.
Another strategy in this area is to give the users another rm command that doesn't actually remove files (at least not right away). The command would move the file to a temporary holding area that is flushed of files older than a predetermined age.
Using disk quotas can protect the system from being overwhelmed by a few users. You can begin restricting disk usage by running quotaon /user_filesystem. That command allows users residing on user_filesystem to be reined in. Defining how much space each user can accumulate results by executing the edquota command. The general form of this command is:
edquota [-p previously_defined_quota_username] username
For example: edquota charlene brings up an edit session that allows (re)setting hard and soft values for total disk space in kilobytes and total number of inodes used. The difference between hard and soft is that hard can never be exceeded. Exceeding the soft limit begins a timer. If the user goes below the soft limit, the timer resets. If the timer alarms, the condition is treated the same as surmounting the hard limit. Edquota -p charlene georgia does not bring up an editor but instead duplicates username charlene quota information for username georgia.
To check on a username, you run quota -v username ... or repquota /user_filesystem. Quota reports a specified username's disk usage and limits. If the -v is left off, only the specified usernames exceeding their limits are output. repquota gives a summary of all users in the password file for the specified file system. Again, disk usage and limits are expressed. An example of the quota command and its output follows.
quota -v jamie Disk quotas for jamie (uid 315): Filesystem usage quota limit timeleft files quota limit timeleft /usr1 26015 25600 30720 5.1 days 488 500 750
Username jamie has exceeded the total kilobyte usage allowed and has 5.1 days left to reduce her usage. That username could create 12 more files before signaling an inode overage (assuming enough space exists).
repquota is a bit different because it lists all users under quota restrictions when run. An example is:
Disk limits File limits User used soft hard timeleft used soft hard timeleft alyssa -- 00417 25600 30720 0043 200 250 james -- 12871 25600 30720 0149 200 250 wayne -+ 04635 25600 30720 1072 500 750 EXPIRED rayna -- 00002 25600 30720 0003 200 250 steve -- 11786 25600 30720 0155 200 250 judy -- 00015 25600 30720 0013 200 250 jamie +- 26015 25600 30720 5.1 days 0488 500 750 holly -+ 11872 25600 30720 0200 200 250 6.0 days kenny -- 02737 25600 30720 0134 200 250 irene -- 02704 25600 30720 0070 200 250 bert -- 03070 25600 30720 0173 200 250 al -- 00613 25600 30720 0021 200 250 connie -- 00558 25600 30720 0025 200 250 charlene -- 00539 25600 30720 0016 200 250 dave +- 50226 50000 60000 EXPIRED 0430 500 750 mike -- 03853 25600 30720 0020 200 250 ann -- 05308 25600 30720 0162 200 250 kirstin -- 20672 25600 30720 0191 300 350 matthew -- 00444 25600 30720 0012 200 250 john -- 01303 25600 30720 0067 200 250
In the example, wayne and dave have faults that disallow use. Users jamie and holly need to lower their use in the specified time period or will have use disallowed. Alternately, the values for their use could be increased.
Though a subset of total disk usage, incoming mail file usage should be monitored specifically since generally all users share a common incoming mail directory space. One "pig" can disrupt the entire system. For example:
ls -l /var/mail | awk `{if ($5 > 500000) printf"%-8.8s - %ld\n", $3, $5}'
will list all usernames with mail files greater than 1/2 million characters. Either the user can politely be asked to reduce the number of messages or you can lessen the file space by saving and compressing or by archiving and deleting it.
Lastly, user administration discussion would not be complete unless it included a description of how to enable a very special, if not insecure, user id. This last section deals with setting up an anonymous ftp account.
First, create a user id for the account in the passwd file. The entry should have a unique user id, the group id matching the user id and an invalid password and shell. An example entry could be:
ftp:*:500:ftp:Anonymous ftp
user:/usr_ftp_home_directory/ftp:/bin/false
Second, create the home directory.
mkdir /usr_ftp_home_directory/ftp
cd /usr_ftp_home_directory/ftp
mkdir bin etc [lib] [dev] pub
mkdir pub/incoming
chown -R root .
chgrp ftp . pub
chmod ugo+rx . pub [lib]
chmod ugo+x bin etc [dev]
chmod u+rwx,o+wx,+t pub/incoming
Third, fill the directories with appropriate information.
cp /bin or /sbin/ls bin
chmod ugo+x bin/ls
[ cp /usr/lib/libdl.so.* lib ]
[ chmod ugo+rx lib/libdl.so.* ]
[ ls -l /dev/zero ]
[ mknod dev/zero c major# minor# ] --- major/minor numbers are the comma seperated
entries directly left of the date in the ouput of the "ls" command.
[ chmod ugo+r dev/zero ]
[ create an etc/passwd file that includes root, daemon, and ftp
whose passwords are "*" ]
[ create an etc/group file that includes the root default group and the ftp group ]
You should now be in the anonymous ftp business. To make sure that things are set up correctly, look at the anonymous ftp directory. No file or directory should be owned by ftp because Trojan horse versions of the files could be inserted. Connect as anonymous ftp, and try to create a file in the current working directory. If you can, anonymous ftp is insecure.
Although it seems a thankless task, user administration is best when it is unnoticed. You should be available to answer questions, but otherwise be invisible to your users. Use the many inherent Unix user administration tools in concert with the select add-on packages to oversee, monitor and limit your user base. Satisfied users free you from the more mundane tasks of user administration and give you the free time to sift through other areas of the system, devoting your time to being productive rather than solving problems.
©Copyright,
Macmillan Computer Publishing. All rights reserved.