Summer 1996 - Lesson 06
Adding New Users
Pretty straightforward - and tedious
A. Steps to adding a user:
--> Number of C library calls (getpwent(), etc.) exist to access
entries in the password file. Many UNIX commands depend on the
file being available, readable, with the proper format.
1. Create an entry in /etc/passwd, selecting a unique 8-char login
name, unique UID, appropriate GID, unique home directory and
appropriate shell.
7 ":" separated fields:
jtbauer:f9cPz5ilB5N0o:2009:20:Jeff Bauer:/home/scri29/users/jtbauer:/bin/csh
Name Password UID GID GECOS Home Directory Shell
Some UNIXes (BSD) provide "vipw", which will lock out other
SysAdmins from editing the /etc/passwd file simultaneously.
2. Make sure group mapping exists in /etc/group, which has the
format:
groupname:password:gid:user-list
where:
groupname is the name of the group.
gid is the group's numerical ID within the system; it must
be unique.
user-list is a comma-separated list of users allowed in
the group (used for multiple-group memberships by
an individual). You may want to edit the membership
list of other groups, if appropriate. Used thusly:
% id
% groups
% touch file1
% newgrp rosters
% touch file2
% ls -lg file1 file2
Example /etc/group:
u1:*:20:
3. Give the user a password: "passwd username" (as root).
4. Edit their disk quota (if disk quotas are in use) via "edquota".
Type "edquota -p protouser username". How do users see their
current quota usage? "quota -v".
NOTE: Not all UNIXes support disk quotas!
5. Make sure the directory exists and has the right permissions and
that the appropriate default startup files are installed in
the home directory (.login, .cshrc, .Xdefaults, etc.; see
Table 6.1, p. 91):
mkdir /home/scri29/users/jtbauer
cp /usr/skel/.[A-Za-z]* /home/scri29/users/jtbauer
chown -R jtbauer.u1 /home/scri29/users/jtbauer
-or-
chown -R jtbauer1 /home/scri29/users/jtbauer
chgrp -R u1 /home/scri29/users/jtbauer
chmod 700 /home/scri29/users/jtbauer
You can do these steps manually, use a vendor-supplied "adduser"
script, or write your own.
SunOS 4.x: "adduser"
SunOS 5.x: "useradd", "usermod", "userdel".
AIX: "smit"
HP-UX: "sam"
Linux: "adduser" (if part of your Linux distribution)
--> The trend is to provide slick GUI interfaces for most of
SysAdmin functions. <--
Many vendors provide a "shadow" password capability -- move the
encrypted password out of the publicly-readable "/etc/passwd" file
and into a root-accessible-only file. WHY?
See "Crack", "satan", "COPS", etc. -- any hacker with CPU cycles to
burn can guess passwords!
Also allows for creation of new fields to support password rules,
password aging, etc. Examples:
SunOS 4.x: /etc/security/passwd.adjunct (See "man passwd.adjunct")
SunOS 5.x: /etc/shadow (See "man shadow")
Linux: See "Shadow Suite":
http://jaka.ece.uiuc.edu/ldp/HOWTO/Shadow-Password-HOWTO.html
NOTE: Excellent source of Linux HOWTOs:
http://jaka.ece.uiuc.edu/ldp/HOWTO/HOWTO-INDEX.html
B. Removing users - just undo the steps above!
o Can be problematic to find all files owned by the user, if you
gave them access to directories out of their home directory.
- One solution: "repquota", if quotas are used.
- Or, "find / -user username -print"
- Don't forget their unread mailbox (/var/spool/mail/username)
C. Disabling users
o One: modify their encrypted password
From:
jtbauer:f9cPz5ilB5N0o:2009:20:Jeff Bauer:/home/jtbauer:/bin/csh
To:
jtbauer:*off*f9cPz5ilB5N0o:2009:20:Jeff Bauer:/home/jtbauer:/bin/csh
o Two: disabling their login shell
jtbauer:*off*f9cPz5ilB5N0o:2009:20:Jeff Bauer:/home/jtbauer:/usr/local/bin/nologin
** Customizing User Authentication **
A. shells
1. /etc/shells - list of trusted shells users can change to via "chsh"
2. CompSci's artificial shells
user classes:
reg, special, pclab, guest, system
shells classes:
sh, csh, tcsh
15 combinations:
reg-csh, reg-tcsh, etc ....
each artificial shell is a link to either:
- a real shell
- /usr/local/bin/nologin
/etc/guest-csh -> /usr/local/bin/nologin
/etc/pclab-csh -> /usr/local/bin/nologin
/etc/system-csh ->/bin/csh
/etc/reg-csh ->/bin/csh
/usr/local/bin/nologin produces:
*********************************************************
* *
* Sorry, but you do not have authorization to log in to *
* this machine. You may have a guest account in which *
* case you should be able to login to xi.cs.fsu.edu. *
* Please contact the system group if you think that you *
* have received this notification in error. *
* *
*********************************************************
then logs you out
B. "/bin/passwd" binary
1. Modify the source code or obtain a better binary ("npasswd" or "passwd+")
2. Require a reasonable choice of password
3. Have a password server where all must "rlogin" into and neuter
"/bin/passwd" on all other machines. CompSci: "rlogin nu";
SCRI: "rlogin sun2".
C. /etc/passwd
1. create a cron script to make backups
cp /saved/passwd.1 /saved/passwd.2
cp /saved/passwd.0 /saved/passwd.1
cp /etc/passwd /saved/passwd.0
A common problem is having the "root" file system fill up and
the password file getting truncated to a zero-length file. What
is the biggest problem now? How can you get around it?
2. use "pwck" (and "grpck") on BSD systems
to make cursory check of these important
files.
3. Occasionally run password crackers to see if your users
are putting in obvious passwords (notice this is less of a problem
if you require them to have creative passwords).
D. Default CompSci "dot" files
/nu1/adm/master
GetDefaultDotFiles
The Filesystem
A. Making a device in "/dev"
Device files provide a connection between a device and
standard UNIX system calls. For filesystems, this is a connection
between the disk drive partition and the eventual mount point.
Identified by a "major" and a "minor" device number, as well
as type "b" (block) or "c" (character, or raw device):
xi->ls -l /dev/sd0a /dev/rsd0a
brw-r----- 1 root 7, 0 May 3 1995 /dev/sd0a
crw-r----- 1 root 17, 0 May 3 1995 /dev/rsd0a
The naming conventions and major/minor device numbers are
extremely machine-specific! See Table 7.3 on page 106.
Major & minor device numbers used to attribute the device
file with the appropriate kernel device driver (see the jump
table description on page 98).
A BSD-derived shell script named "/dev/MAKEDEV" does the work on
SunOS 4.x and Linux.
Look at line for nit: "mk nit c 37 40 600" -- it boils down
to a "mknod" command.
Note that the naming conventions vary even between different
versions of the operating system. SunOS 5.x, for example,
provides backwards compatiblity with the old names:
touch->ls -l /dev/sd0a /dev/rsd0a
lrwxrwxrwx 1 root root 13 May 4 1995 /dev/rsd0a ->
rdsk/c0t3d0s0
lrwxrwxrwx 1 root root 12 May 4 1995 /dev/sd0a ->
dsk/c0t3d0s0
touch->ls -l rdsk/c0t3d0s0 dsk/c0t3d0s0
lrwxrwxrwx 1 root root 86 May 4 1995 dsk/c0t3d0s0 ->
../../devices/iommu@0,10000000/sbus@0,10001000/espdma@4,8400000/esp@4,8800000/sd@3,0:a
lrwxrwxrwx 1 root root 90 May 4 1995 rdsk/c0t3d0s0 ->
../../devices/iommu@0,10000000/sbus@0,10001000/espdma@4,8400000/esp@4,8800000/sd@3,0:a,raw
/dev/dsk/cntndnsn block files
/dev/rdsk/cntndnsn raw files
where:
cn controller n
tn SCSI target id n (0-6)
dn SCSI LUN n (0-7)
sn partition n (0-7)
SunOS 5.x also does not have a "/dev/MAKEDEV"; the devices
files are created on-the-fly at boot time, when the kernel
detects the hardware. A utility named "devconfig" can be used to
help this process.
Also, most kernels these days (including Linux) allow for dynamic loading of kernel
modules and device drivers (see section 7.5 on page 106).
--> Will cover adding disks to the system in Chapter 9. <--
B. symbolic links
- "ln -s file_to_link_to name_of_link"
- Can span file systems
- Can get stale (no kernel enforcement of valid symlinks), thus a
potential for sysadmin overuse.
C. setuid and setgid bits
1. suid and setgid on executables - the effective UID and GID of
the user executing the program temporarily becomes the UID and
GID of the owner of the file, if the suid and guid bits
are set ("chmod 4xxx", "chmod 2xxx", "chmod 6xxx", "chmod u+s",
"chmod g+s", etc. -- see "man chmod" for details).
2. setgid on directory - if set, files inherit the group ID
of the directory (a BSD semantic) and not the group ID of
the creator.
- if a file has setgid bit set and group execute
bit cleared then mandatory record locking is in
effect:
rwxr-Sr-x # the "S" indicates setgid set, but group execute not set
D. sticky bit
On a plain file, the sticky bit indicates that the binary should
remain in memory after the last user finishes executing the text
segment -- the program "sticks" in memory. Typically only settable
by root and used to keep commonly-used programs in memory for
quicker response. This use of the sticky bit has pretty much fallen out
of use with quicker machines and better virtual memory/caching kernels.
On a directory, the sticky bit does (from "man -s 2 chmod"):
If a directory is writable and has S_ISVTX (the sticky bit)
set, files within that directory can be removed or renamed
only if one or more of the following is true (see unlink(2)
and rename(2)):
o the user owns the file
o the user owns the directory
o the file is writable by the user
o the user is a privileged user
Example: shared directories - /tmp and /var/spool/mail
drwxrwsrwt 3 bin staff 512 Jan 27 11:40 tmp
- see xi:/tmp/try_to_delete_me
- /also /var/spool/mail
E. permissions try for access in the following order:
1. owner
2. group
3. all
- you are thwarted at first failure
F. Some UNIXes extend the 9-bit "rwxrwxrwx" permissions to generalized
access lists (AIX, HP-UX, for example). You can control file access
with more flexibility, using commands like "aclget", "aclput", etc.
G. Directory permissions
- 'r' bit allows one to read directory
- 'x' allows one to enter directory
H. inodes - UNIX information node
0. Unique per file system.
1. The inode for a file holds most information about a file:
size, pointer to 1st disk block, file permission bits,
timestamps (file accessed ("ls -lu") , file modified ("ls -l"),
inode modified "ls -lc"), etc.
2. The directory entry only holds a name-inode pair
3. The "ls" command is a window into the inode (try "ls -li")
4. Actual data structures:
/usr/include/ufs/inode.h (SunOS 4.x)
/usr/include/sys/fs/ufs_inode.h (SunOS 5.x)
/usr/include/linux/fs.h (Linux)