|
UNIX Hints & Hacks |
 |
||||||||||||||||||||||||||||||||||||
|
Chapter 5: Account Management |
|
||||||||||||||||||||||||||||||||||||
|
Not only do UIDs need to be unique, they need to be managed from a central point within your environment.
Flavors: All
A UID can range from 0 to 32,767. The possibility of so many numbers being propagated to such a large number of users has the potential of getting out of control very fast and becoming an administrative nightmare. This definitely holds true at any large corporation or educational facility. A designated administrator or centralized UID file should be set in place for delegating and managing the UIDs that are issued and reclaimed. They should consist of the UID and all available information on the user that owns the UID.
Flavors: AT&T, BSD
Shells: All
Syntax:
chown -R [UID] [dirs|files]
Things are always simple when there are new systems with new or continued users, but what can be done to an existing user that has been working standalone on a different network? There are times when users acquire systems without your knowledge. They might even have the capability to bring the system up on their own or enlist the help of a power user and apply the necessary network information to bring it up talking on the network. In doing so, users often decide, or are told by a vendor or another user, to accept the defaults when creating an account for themselves. The day usually arrives when they call and ask to have their systems mounted to or from other machines on the network and need to share files with other users. Keep in mind, this could be your first contact with the user.
You now have to inform them--no, convince them--that the gigabytes of data they created might all need to be touched or modified with a new UID before they can mount their computers over the network. Because they might have accepted the defaults in creating an account, there is an almost-guaranteed chance that their UID conflicts with another UID. In working with the user on this issue, let them know up front what is involved and what the repercussions are in performing or not performing this process.
If a UID is conflicting with multiple users, all users are at risk of having full access to each other's files. The password entry needs to be modified with a new UID for the user. You can assure the user that the content of the files will not be touched. It is a nonintrusive recursive action. The time stamps on the files would even still remain the same.
# chown -R 564 /home/bill
They would still maintain ownership on all the files, and no one else would be able to gain access to their files unless the permissions were lowered on the file by the user. Assure them this would be at their discretion.
If this is not controlled, existing machines that need to be part of your network can present an internal security risk to you, your user community, and your environment.
If two different systems share a common password file that has multiple users with the same UID, one user might notice someone else having ownership of their files. This is a common scenario. There is a way for two users to share the same UID and have complete access to each other's files without even knowing the conflict exists. It works like this:
Bill is on the host called rocket and Tom is on the host called saucer. They both have the same UID in their local password files on each of their own hosts. Each host has an NFS mount point to the filesystem / disk2 on a third host, planet.
Password Entry: bill:ypt5jSOS7ha.s:125:20:Bill Adams:/home/bill:/bin/tcsh Mount: planet:/disk2 nfs 8360424 3619992 4740432 44 /disk2
Host: saucer
Password Entry: tom:kThFG24y4l.j4:125:20:Tom Irvine:/home/bill:/bin/tcsh Mount: planet:/disk2 nfs 8360424 3619992 4740432 44 /disk2
If you follow the path of /disk2 to an area in the filesystem that both users work in, you should be able to find files that would appear to be owned by both users.
Host: rocket
% cd /disk2/files % ls -al -rwxr----- 1 bill user 640 Oct 9 9:24 asdb.pl* -rw-r----- 1 bill user 4512 Jun 5 10:55 database.log -r--r----- 1 bill user 123 Oct 21 8:12 record.dat
Host: Saucer
% cd /disk2/files % ls -al -rwxr----- 1 tim user 640 Oct 9 9:24 asdb.pl* -rw-r----- 1 tim user 4512 Jun 5 10:55 database.log -rw-r----- 1 tim user 123 Oct 21 8:12 record.dat
Because the file is owned by the UID 125, both system recognize the files as being owned by the local user defined in the /etc/password file.
Man pages:
chown, mount, passwd
|
UNIX Hints & Hacks |
|
||||||||||||||||||||||||||||||||||||
|
Chapter 5: Account Management |
|
||||||||||||||||||||||||||||||||||||
|
© Copyright Macmillan USA. All rights reserved.