- 论坛徽章:
- 0
|
有关相同UID的用户权限的问题？
第一次問問題的帖子當然是要支持的。
下面的文章很好，放在這裏我們一起學習吧。
Guidelines for Managing User Accounts
The following sections describe some guidelines and planning information for creating user accounts.
Name Services
If you are managing user accounts for a large site, you may want to consider using a name service such as NIS or NIS+. A name service enables you to store user account information in a centralized manner instead of storing user account information in every system's /etc files. When using a name service for user accounts, users can move from system to system using the same user account without having site-wide user account information duplicated in every system's /etc files. Using a name service also promotes centralized and consistent user account information.
User (Login) Names
User names, also called login names, let users access their own systems and remote systems that have the appropriate access privileges. You must choose a user name for each user account you create. User names must:
*
Be unique within your organization, which may span multiple domains
*
Contain from two to eight letters and numerals (the first character must be a letter and at least one character must be a lowercase letter)
*
Not contain an underscore or space
It is helpful to establish a standard way of forming user names, and the names should be easy for users to remember. A simple scheme when selecting a user name is to use the first name initial and first seven letters of the user's last name. For example, Ziggy Ignatz becomes zignatz. If that scheme results in duplicate names, you can use the first initial, middle initial, and the first six characters of the user's last name. For example, Ziggy Top Ignatz becomes ztignatz. If that still results in duplicate names, you can use the first initial, middle initial, first five characters of the user's last name, and the number 1, or 2, or 3, and so on, until you have a unique name.
Note -
Each new user name must be distinct from any mail aliases known to the system or to an NIS or NIS+ domain. Otherwise, mail may be delivered to the alias rather than to the actual user.
User ID Numbers
Associated with each user name is a user identification (UID) number. The UID number identifies the user name to any system on which the user attempts to log in, and it is used by systems to identify the owners of files and directories. If you create user accounts for a single individual on a number of different systems, always use the same user name and user ID. In that way, the user can easily move files between systems without ownership problems.
UID numbers must be a whole number less than or equal to 2147483647, and they are required for both regular user accounts and special system accounts. Table 1-1 lists the UID numbers reserved for user accounts and system accounts.
Table 1-1 Reserved UID Numbers
User ID Numbers
Login Accounts
Reserved For ...
0 - 99
root, daemon, bin, sys, etc.
System accounts
100 - 2147483647
Regular users
General purpose accounts
60001
nobody
Unauthenticated users
60002
noaccess
Compatibility with Solaris 2.0 and compatible versions and SVR4 releases
Although UID numbers 0 through 99 are reserved, you can add a user with one of these numbers. However, do not use them for regular user accounts. By definition, root always has UID 0, daemon has UID 1, and pseudo-user bin has UID 2. In addition, you should give uucp logins and pseudo user logins, like who, tty, and ttytype, low UIDs so they fall at the beginning of the passwd file.
As with user (login) names, you should adopt a scheme to assign unique UIDs. Some companies assign unique employee numbers, and administrators add 1000 to the employee number to create a unique UID number for each employee.
To minimize security risks, you should avoid reusing the UIDs from deleted accounts. If you must reuse a UID, "wipe the slate clean" so the new user is not affected by attributes set for a former user. For example, a former user may have been denied access to a printer--by being included in a printer deny list--but that attribute may not be appropriate for the new user. If need be, you can use duplicate UIDs in an NIS+ domain if the supply of unique UIDs is exhausted.
Using Large User IDs and Group IDs
Previous Solaris software releases used 32-bit data types to contain the user IDs (UIDs) and group IDs (GIDs), but UIDs and GIDs were constrained to a maximum useful value of 60000. Starting with the Solaris 2.5.1 release and compatible versions, the limit on UID and GID values has been raised to the maximum value of a signed integer, or 2147483647.
UIDs and GIDs over 60000 do not have full functionality and are incompatible with many Solaris features, so avoid using UIDs or GIDs over 60000. See Table 1-2 for a complete list of interoperability issues with Solaris products and commands.
Table 1-2 describes interoperability issues with previous Solaris and Solaris product releases.
Table 1-2 Interoperability Issues for UIDs/GIDs Over 60000
Category
Product/Command
Issues/Cautions
NFSTM Interoperability
SunOS 4.0 NFS software and compatible versions
NFS server and client code truncates large UIDs and GIDs to 16 bits. This can create security problems if SunOS 4.0 and compatible machines are used in an environment where large UIDs and GIDs are being used. SunOS 4.0 and compatible systems require a patch.
Name Service Interoperability
NIS name service File-based name service
Users with UIDs above 60000 can log in or use the su command on systems running the Solaris 2.5 and compatible versions, but their UIDs and GIDs will be set to 60001 (nobody).
NIS+ name service
Users with UIDs above 60000 are denied access on systems running Solaris 2.5 and compatible versions and the NIS+ name service.
Printed UIDs/GIDs
OpenWindows File Manager
Large UIDs and GIDs will not display correctly if the OpenWindowsTM File Manager is used with the extended file listing display option.
Table 1-3 Large UID/GID Limitation Summary
A UID or GID Of ...
Limitations
60003 or greater
*
Users in this category logging into systems running Solaris 2.5 and compatible releases and the NIS or files name service will get a UID and GID of nobody.
65535 or greater
*
Solaris 2.5 and compatible releases systems running the NFS version 2 software will see UIDs in this category truncated to 16 bits, creating possible security problems.
*
Users in this category using the cpio command (using the default archive format) to copy files will see an error message for each file and the UIDs and GIDs will be set to nobody in the archive.
*
SPARC systems: Users in this category running SunOS 4.0 and compatible applications will see EOVERFLOW returns from some system calls, and their UIDs and GIDs will be mapped to nobody.
*
x86 systems: Users in this category on x86 systems running SVR3-compatible applications will probably see EOVERFLOW return codes from system calls.
*
x86 systems: If users in this category attempt to create a file or directory on a mounted System V file system, the System V file system returns an EOVERFLOW error.
100000 or greater
*
The ps -l command displays a maximum five-digit UID so the printed column won't be aligned when they include a UID or GID larger than 99999.
262144 or greater
*
Users in this category using the cpio command (using -H odc format) or the pax -x cpio command to copy files will see an error message returned for each file, and the UIDs and GIDs will be set to nobody in the archive.
1000000 or greater
*
Users in this category using the ar command will have their UIDs and GIDs set to nobody in the archive.
2097152 or greater
*
Users in this category using the tar command, the cpio -H ustar command, or the pax -x tar command have their UIDs and GIDs set to nobody.
Passwords
Although user names are publicly known, passwords must be kept secret and known only to users. Each user account should be assigned a password, which is a combination of six to eight letters, numbers, or special characters. You can set a user's password when you create the user account and have the user change it when logging in to a system for the first time.
To make your computer systems more secure, ask users to change their passwords periodically. For a high level of security, you should require users to change their passwords every six weeks. Once every three months is adequate for lower levels of security. System administration logins (such as root and sys) should be changed monthly, or whenever a person who knows the root password leaves the company or is reassigned.
Many breaches of computer security involve guessing a legitimate user's password. You should make sure that users avoid using proper nouns, names, login names, and other passwords that a person might guess just by knowing something about the user.
Good choices for passwords include:
*
Phrases (beammeup)
*
Nonsense words made up of the first letters of every word in a phrase (swotrb for SomeWhere Over The RainBow)
*
Words with numbers or symbols substituted for letters (sn00py for snoopy)
Do not use these choices for passwords:
*
Your name, forwards, backwards, or jumbled
*
Names of family members or pets
*
Car license numbers
*
Telephone numbers
*
Social Security numbers
*
Employee numbers
*
Names related to a hobby or interest
*
Seasonal themes, such as Santa in December
*
Any word in the dictionary
Password Aging
If you are using NIS+ or the /etc files to store user account information, you can set up password aging on a user's password. Password aging enables you to force users to change their passwords periodically or to prevent a user from changing a password before a specified interval. If you want to prevent an intruder from gaining undetected access to the system by using an old and inactive account, you can also set a password expiration date when the account will be disabled.
Home Directories
The home directory is the portion of a file system allocated to a user for storing private files. The amount of space you allocate for a home directory depends on the kinds of files the user creates and the type of work done. As a general rule, you should allocate at least 15 Mbytes of disk space for each user's home directory.
A home directory can be located either on the user's local system or on a remote file server. In either case, by convention the home directory should be created as /export/home/username. For a large site, you should store home directories on a server. Use a separate file system for each /export/homen directory to facilitate backing up and restoring home directories (for example, /export/home1, /export/home2).
Regardless of where their home directory is located, users usually access their home directories through a mount point named /home/username. When AutoFS is used to mount home directories, you are not permitted to create any directories under the /home mount point on any system. The system recognizes the special status of /home when Autofs is active. For more information about automounting home directories, see the NFS Administration Guide.
To use the home directory anywhere on the network, you should always refer to it as $HOME, not as /export/home/username. The latter is machine-specific. In addition, any symbolic links created in a user's home directory should use relative paths (for example, ../../../x/y/x), so the links will be valid no matter where the home directory is mounted.
The User's Work Environment
Besides having a home directory to create and store files, users need an environment that gives them access to the tools and resources they need to do their work. When a user logs in to a system, the user's work environment is determined by initialization files that are defined by the user's startup shell, such as the C, Korn, or Bourne shell.
A good strategy for managing the user's work environment is to provide customized user initialization files (.login, .cshrc, .profile) in the user's home directory. See "Customizing a User's Work Environment" for detailed information about customizing user initialization files for users. After you create the customized user initialization files, you can add them to a user's home directory when you create a new user account.
A recommended one-time task is to set up separate directories, called skeleton directories, on a server (you can use the same server where the user's home directories are stored). The skeleton directories enable you to store customized user initialization files for different types of users.
Note -
Do not use system initialization files (/etc/profile, /etc/.login) to manage a user's work environment, because they reside locally on systems and are not centrally administered. For example, if AutoFS is used to mount the user's home directory from any system on the network, then you would have to modify the system initialization files on each system to ensure a consistent environment when a user moves from system to system. |
|
免费注册
发表于 2004-07-26 22:23
