unx36.htm

Linux Unix揭密.高质量电子书籍.对学习Linux有大帮助,欢迎下载学习.

#    >>>>>>>>>>     The program "newaliases" will need to be run 

#    >> NOTE >> after    this file is updated for any changes to

#    >>>>>>>>>>     show through to sendmail.

##

# Following alias is required by the mail protocol, RFC 822

# Set it to the address of a HUMAN who deals with this system's 

Postmaster: root

nobody: /dev/null

# Sample aliases:

# Alias for distribution list, members specified here:

#staff:wnj,mosher,sam,ecc,mckusick,sklower,olson,rwh@ernie

# Alias for distribution list, members specified elsewhere:

#keyboards: :include:/usr/jfarrell/keyboards.list

# Alias for a person, so they can receive mail by several names:

#epa:eric

#######################

# Local aliases below #

#######################

Syd.Weinstein:      syd

Sydney.Weinstein:   syd</PRE>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="imp.gif" WIDTH = 68 HEIGHT = 35><B>TIP:</B> As demonstrated in the end of Listing 36.1, it is wise to create full-name aliases. These aliases let someone be addressed by their full name, without the sender knowing the user name. Since aliases are 

case insensitive, it doesn't matter how you list the full name. Remember, however, that delivery addresses (the part after the colon) are case sensitive.

<BR></NOTE>

<HR ALIGN=CENTER>

<P>An alias can point to another alias. Aliases listed in this file are systemwide, and are addresses to which another user can reply. This is not true of private aliases users might enter into their mail reader's start-up files.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I8" NAME="I8">

<FONT SIZE=3><B>The Shell Start-up Files</B>

<BR></FONT></A></CENTER></H4>

<P>Each user interacts with UNIX via a command shell. The command shells use a file in the user's home directory to customize themselves for each user. As administrator, it is your responsibility to provide a default shell customization file. There are two 

different sets of customization files&#151;the one you use depends on the shell family being used. For shells that are derived from /bin/sh the initialization file is .profile, with the Korn shell using an additional file whose name is user definable, but 

is often called .ksh_env. Shells derived from Berkeley's C-shell use .login and .cshrc. A short explanation of the purpose and contents of these 4 files is as follows:

<BR></P>

<UL>

<LI>.profile

<BR>

<BR>This is the start-up file executed by Bourne (/bin/sh) and Korn (/bin/ksh) shells at login. This is the file where you place changes to environment variables and global settings. This file is executed after /etc/profile is executed.

<BR>

<BR></LI>

<LI>.ksh_env

<BR>

<BR>The Bourne shell does not have a start-up file for non&#151;login-level shells. The Korn shell does, as it supports aliases and functions that are not exported from the login shell to subshells. If the login shell, via the .profile file, exports the 
variable ENV, each Korn shell will read the file named in that environment variable on start-up. This file should not include changes to environment variables, but should include function and alias definitions. For login shells, this file is run after 
/etc/profile and .profile. For subshells, it is the only file executed.

<BR>

<BR></LI>

<LI>.login

<BR>

<BR>This file is run only at login by the C-shell. It should contain environment variable and global settings. It is executed after /etc/cshrc and .cshrc are executed.

<BR>

<BR></LI>

<LI>.cshrc

<BR>

<BR>This file is run by all C-shells at start-up. It is used to initialize aliases and local variables. Changes to environment variables should not be made in this file. For login shells, this file is run after /etc/cshrc and before .login. For subshells, 

it is the only file executed.

<BR>

<BR></LI></UL>

<H4 ALIGN="CENTER">

<CENTER><A ID="I9" NAME="I9">

<FONT SIZE=3><B>The User's </B><B><I>passwd</I></B><B> File Entry or NIS/NIS+ Database Entry</B>

<BR></FONT></A></CENTER></H4>

<P>The system keeps track of users via an entry in the password database. This databases is maintained in the following ways:

<BR></P>

<UL>

<LI>traditionally&#151;in /etc/passwd

<BR>

<BR></LI>

<LI>SVR4 style&#151;in /etc/passwd and /etc/shadow

<BR>

<BR></LI>

<LI>NIS/NIS+&#151;in a networkwide database, and on the NIS/NIS+ master in files specified at the time that NIS/NIS+ is configured.

<BR>

<BR></LI></UL>

<P>It really doesn't matter which method is used because all of them track the same information. It is this information that defines the user to the UNIX system.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="caution.gif" WIDTH = 37 HEIGHT = 35><B>CAUTION:</B> In a networked environment, it is very important that every system on the network use the same user ID for the same user. Although NIS and other methods share the password information to achieve 

this, that is not required. All that is required is that any systems that share files via NFS also share user IDs.

<BR></NOTE>

<HR ALIGN=CENTER>

<P>The passwd file, as shown in Listing 36.2, is composed of single-line entries. Each must appear on a single line and cannot be continued. All the lines must have seven fields, delimited by colons. No comments or blank lines are allowed in this file. 
This file is world readable, so it does not contain plain-text passwords.

<BR></P>

<UL>

<LH><B>Listing 36.2. Excerpts from a sample </B><B>/etc/passwd</B><B> file from an SVR4 </B><B>system.</B></LH></UL>

<PRE>root:x:0:1:0000-Admin(0000):/:/sbin/sh

daemon:x:1:1:0000-Admin(0000):/:

bin:x:2:2:0000-Admin(0000):/usr/bin:

sys:x:3:3:0000-Admin(0000):/:

adm:x:4:4:0000-Admin(0000):/var/adm:

lp:x:71:8:0000-lp(0000):/usr/spool/lp:

smtp:x:0:0:mail daemon user:/:

uucp:x:5:5:0000-uucp(0000):/usr/lib/uucp:

nuucp:x:9:9:0000-uucp(0000):/var/spool/uucppublic:/usr/lib/uucp/uucico

listen:x:37:4:Network Admin:/usr/net/nls:

syd:x:201:200:Syd Weinstein:/home/syd:/usr/bin/ksh

Pwcsite:x:9001:9:PPP from wc:/:/usr/sbin/aspppls

nobody:x:60001:60001:uid no body:/:

noaccess:x:60002:60002:uid no access:/:</PRE>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="caution.gif" WIDTH = 37 HEIGHT = 35><B>CAUTION:</B> Be very careful that all the lines have six colons separating the seven fields. A blank line will be taken as an alternate entry for the root user with no password.

<BR></NOTE>

<HR ALIGN=CENTER>

<P>The seven fields, in order, in the passwd file are described in the following sections.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I10" NAME="I10">

<FONT SIZE=3><B>User Name</B>

<BR></FONT></A></CENTER></H5>

<P>This is a one- to eight-character alphanumeric field that represents the user's login name. Traditionally the name is all lowercase characters. Any value may be used for this field. To make it easy to tell a user name from a user ID, the name should not 

start with a number.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="imp.gif" WIDTH = 68 HEIGHT = 35><B>TIP:</B> Accounts fall into two basic categories: human users and computer users. UUCP accounts are an example of the latter. To make it easy to spot accounts that are used by other computers to log in for uucp 

transfers, a convention is to start all those user names with an uppercase U.

<BR></NOTE>

<HR ALIGN=CENTER>

<H5 ALIGN="CENTER">

<CENTER><A ID="I11" NAME="I11">

<FONT SIZE=3><B>Password (if Not Using a Shadow Password Scheme)</B>

<BR></FONT></A></CENTER></H5>

<P>The users password, encrypted with a one-way cipher is stored in the second field. Only the first 8 characters of the password are used. These are mixed with a 2-character salt to produce a 13-character encrypted password. When it is necessary to 
compare a password, the plain text is encrypted with the salt, and a comparison is made against the encrypted version. If the passwd field is empty, this account has no password, and none is required to log in.

<BR></P>

<P>On systems that support password aging and place the password in the passwd file, the password data can be followed by a comma and four characters that describe the aging information. Each of these characters is drawn from the following character set:

<BR></P>

<UL>

<LI>. = 0

<BR>

<BR></LI>

<LI>/ = 1

<BR>

<BR></LI>

<LI>0&#151;9 = 2&#151;11

<BR>

<BR></LI>

<LI>A&#151;Z = 12&#151;37

<BR>

<BR></LI>

<LI>a&#151;z = 38&#151;63

<BR>

<BR></LI></UL>

<P>The first character after the comma denotes the maximum number of weeks the password is valid. The second character is the minimum number of weeks required between password changes. If both of these characters are zero (..), the user is forced to change 

his password the next time he logs in. If the change interval is larger than the valid interval, only the root user can change the password.

<BR></P>

<P>The remaining two characters are the number of weeks since the epoch when the password was last changed. In UNIX, the current epoch, or beginning of time, is January 1, 1970, 00:00 GMT.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="note.gif" WIDTH = 35 HEIGHT = 35><B>NOTE:</B> You must manually edit the passwd file to set the aging characters the first time. They are not created automatically by the system. Be sure to use vipw when editing the passwd file to be sure it is 
locked while you are in it.

<BR></NOTE>

<HR ALIGN=CENTER>

<P>On systems that do not use the passwd file to hold the password, such as those using /etc/shadow or some password adjunct scheme, this field contains a fixed string that has fewer than 13 characters.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="imp.gif" WIDTH = 68 HEIGHT = 35><B>TIP:</B> If you need to temporarily lock out a user, insert the string *LK* on the front of that user's encrypted password string. It now will never match any valid password, as the encryption string uses the 
same character set as the aging characters, and * is not in the set. You can delete *LK* from the front when you need to re-enable the account, and the original password is intact.

<BR></NOTE>

<HR ALIGN=CENTER>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="note.gif" WIDTH = 35 HEIGHT = 35><B>NOTE:</B> To lock an account against being used for logins, use a fixed string that contains an invalid password character to prevent logins. The convention is to use *LK* for accounts that are locked against 
login.

<BR></NOTE>

<HR ALIGN=CENTER>

<H5 ALIGN="CENTER">

<CENTER><A ID="I12" NAME="I12">

<FONT SIZE=3><B>User ID</B>

<BR></FONT></A></CENTER></H5>

<P>UNIX internally uses a numeric ID to refer to a user. This is the user ID field of the passwd file. It is a number in the range 0&#151;32767 on older systems, 0&#151;65535 on some systems, and 0&#151;2147483648 on SVR4 systems. The number 0 is reserved 

for the root user, the user with special privileges. Many networked systems save -1 for no access and -2 for nobody.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="caution.gif" WIDTH = 37 HEIGHT = 35><B>CAUTION:</B> These two values, -1 and -2, have been known to be a security hole. On systems that did not handle sign extension correctly in the user ID, any user ID that mapped to a negative value caused a 
security hole due to other assumptions those systems made about checking. They have been replaced by positive values for noaccess and nobody.

<BR>

<BR>noaccess is the value to use when a file is to be made so that it is not owned by root, but no one will be able to access it. nobody is used by NFS. Remote users with the ID 0 (root) are mapped to the nobody ID on NFS accesses unless the file system is 

exported with root access permission. See Chapter 37, &quot;Networking,&quot; for more details.

<BR></NOTE>

<HR ALIGN=CENTER>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="imp.gif" WIDTH = 68 HEIGHT = 35><B>TIP:</B> Although you have total control over the user IDs, it is best to follow a convention that will make it easier to determine which IDs are being used for which purpose.

<BR>

<BR>UNIX has several accounts that are required. These all have low numbered IDs. It's wise to reserve all the IDs below 100 for these reserved system accounts.

<BR>

<BR>In addition, there are several accounts that are for nonhuman use. These include UUCP access accounts and file ownership accounts. (A file ownership account is one that has no person associated with it, but is designed to hold the ownership of a set of 

files for a department. Then when changes to those files need to be made, any member of the department can su to that user to make the changes.

<BR>

<BR>Consider breaking the numbering space apart into the following:

<BR>

<UL>

<LI>Restricted accounts&#151;system use: 0&#151;99

<BR></LI>

<LI>Networkwide user accounts&#151;100&#151;19999

<BR></LI>

<LI>System restricted user accounts&#151;20000&#151;29999 (These are still unique on the network, but the account is valid only on one system.)

<BR></LI>

<LI>UUCP access accounts&#151;30000&#151;30999

<BR></LI>

<LI>File ownership accounts&#151;31000&#151;31999

<BR></LI>

<LI>nobody&#151;32000

<BR></LI>

<LI>noaccess&#151;32001

<BR></LI></UL>

Of course, if you need more accounts than this scheme supports, and if your system supports extended user IDs, move the regions around to make them bigger.

<BR></NOTE>

<HR ALIGN=CENTER>

<H5 ALIGN="CENTER">

<CENTER><A ID="I13" NAME="I13">

<FONT SIZE=3><B>Default Group ID</B>

<BR></FONT></A></CENTER></H5>

<P>UNIX file permissions have three fields: owner (user ID), group (group ID), and world. The default group for files created by this user is the ID listed for this field. Groups are listed in the file /etc/group or in the file specified by the NIS/NIS+ 
configuration.