Brief History of Unix
Commonly Used Unix Distributions
Users and file permissions
The system boot process
Network Daemon Processes
In The Beginning……
The UNIX “epoch” is January 1st
1970 (technically it was created in 1969.)
System V Unix AT&T (Bell Labs)
System V Rev. 4 is the latest.
BSD Unix UC Berkeley (1979) Released
Unix is a multi-user OS written
mostly in C
AIX - IBM Corp.
DG-UX - Data General Corp. (run away, run away!)
HP-UX - Hewlett Packard Co.
IRIX - Silicon Graphics Inc. (SGI)
SCO - Santa Cruz Operation, Inc
Solaris - Sun Microsystems (System V)
SunOS 4.x - Sun Microsystems (BSD)
Tru64 - Was DEC-Digital Unix, now Compaq Tru64.
Ultrix - DEC’s version of Unix before Digital Unix
Linux (Several distributions)
BSDs (FreeBSD/BSDI, OpenBSD,NetBSD)
New to Unix?
Usenet News comp.unix.*
Unix FAQ from ftp://rtfm.mit.edu
Unix Guru Universe http://www.ugu.com
The Linux Documentation Project:
“Super User” Root can view and
or modify any file or process on the system.
“users” can only view or modify
files for which they have permission. They can only modify processes
that they own.
-rwxrwxrwx 1 jake staff
686 Feb 20 11:56 myfile.txt
user group other
SUID - Set user
When an executable is SUID, it
runs with the privileges of the owner of the executable.
Some system binaries are SUID root
to allow “average” users the ability to perform necessary tasks.
When an executable is SGID, it
runs with the group designation specified on the file.
For example logging in to the
The login program, that runs when a user logs in, is SUID
root so that the process can read the shadow file.
(The shadow file is only
readable by root)
r-sr-xr-x 1 root bin 29292 Oct 6 1998 login
The SUID bit is shown as an “s”
in the user’s execute portion of the file permissions when using the
command “ls -al”
Booting the system
The process of booting a system
is slightly different between BSD and System V UNIX.
We will be focusing on System V process of booting since it is becoming the Linux standard in most distributions and Linux will be used in the class Lab.
At the first step in the boot
process the system BIOS checks the system hardware.
The BIOS then reads the instructions
on the MBR (Master Boot Record) stored on the first sector of the hard
With a Linux system, the MBR
typically loads the LILO (Linux Loader) program.
LILO proceeds to boot the kernel which initializes memory, loads device drivers, then launches the “init” process.
The “init” process is the mother
of all processes, with a process ID of 1.
Init is responsible for starting
all the system processes at boot time, and re-spawning some if they
terminate while the system is running.
The file /etc/inittab configures
the behavior of the init process, and specifies the default run level.
See the man pages for init and
inittab for more details.
Kicking it old
school (Sys V style)
System V UNIX introduced the concept of runlevels.
Different processes are started at each run level.
0 - Halted
1 - Single User
2 - Linux: Not used, SYSV: Multi-user without NFS
3 - Multi-user with NFS
4 - Not Used
5 - Linux: Full Multi-user with X Login, SYSV: Halt, power off
6 - Reboot
Sys V init cont…
The inittab is configured to
instruct init to run /etc/rc.sysinit first. It is a shell script which
initializes the system, mounts local file systems and starts network
Init then launches /etc/rc.d/rc x
which parses the directories /etc/rc.d/rcx.d (where x is the runlevel 0-6).
SysV: Init starts with x=1 and increments till it reaches the default run level specified in inittab
Linux: Init uses x=default run level and parses /etc/rc.d/rcx.d
Sys V init cont….
The directories /etc/rc.d/rcx.d contain shell scripts which start and stop services and/or daemons. An example of a script name is S99sshd.
As the directories are parsed, /etc/rc.d/rc executes the scripts in numeric and alphabetic order with the argument of start.
(Ex: S99sshd start)
This process is continued until the last script of the default run level is executed, then init spawns a getty process to present the login prompt.
Alternatively at shutdown, init parses the same directories as it decrements run levels with the argument of stop.
Logging in: The
The file /etc/passwd contains
information about valid user’s of the UNIX system.
/etc/passwd has several fields separated by a ‘:’
The fields are
Username:Encrypted Password:UserID:GroupID:GCOS(Comment) :HomeDirectory:login shell
Notice the x in the Encrypted Password field. This
indicates that shadow passwords are being used.
Logging in: The
All UNIX systems have /etc/passwd,
but not all have /etc/shadow
/etc/shadow contains a corresponding
user entry from /etc/passwd, and additional fields seperated by a :
The fields are:
Logging in: Login
process (Very Brief)
The “login” process handles all
user logins from terminal sessions. The log on each user must present
their username and password.
The login process verifies that
an entry in /etc/passwd exists for the user.
The login process then, using a “salt”, encrypts the entered password and compares it to the encrypted password in /etc/passwd or /etc/shadow. (Depending if shadowed passwords are used or not.)
If the encrypted passwords match,
you’re allowed in!
Inetd is often referred to as the “Internet super server”
The inetd process oversees several other network daemons which provide specific services such as ftp, telnet, rlogin etc… as defined in its configuration file /etc/inetd.conf
For example: Telnet
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
The keyword “telnet” now needs a corresponding entry in /etc/services to tell the system which port it’s listening.
In this example inetd has been configured to handle incoming telnet requests.
Inetd listens on tcp port 23 for incoming connections.
When a valid connection is received, inetd then spawns a telnet process (in.telnetd) to handle the request.
Why? - Inetd cuts
down on the number of processes running on the system. Processes spawned
by inetd will only run as long as they are needed.
Some Internet service daemons
are spawned by inetd, and others run as stand-alone daemons the listen
on a particular port.
Stand-alone daemons such
as httpd fork() a child process to handle each connection.
A default installation of
most UNIX systems install and start several daemons by default
such as portmap/rpcbind, nfsd, httpd, lpd….)
The ps (process status) command can be used
to view the current running processes
the kill command can be used to send a signal to a process to terminate, restart or reconfigure the process.
See the kill and signal man pages for more details
Commonly used signals:
1 (HUP) - Tells a process to re-read its configuration file
15 (TERM) - Tells a process to terminate
- Forces a process to die when it doesn’t respond to a TERM
processes with “ps”
Output of “ps -aux”
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 2.2 0.8 1324 536 ? S 21:20 0:05 init 
root 2 0.0 0.0 0 0 ? SW 21:20 0:00 [kflushd]
root 3 0.0 0.0 0 0 ? SW 21:20 0:00 [kupdate]
root 4 0.0 0.0 0 0 ? SW 21:20 0:00 [kpiod]
root 5 0.0 0.0 0 0 ? SW 21:20 0:00 [kswapd]
root 6 0.0 0.0 0 0 ? SW< 21:20 0:00 [mdrecoveryd]
root 334 0.2 1.3 1660 844 ? S 21:21 0:00 syslogd -m 0
root 344 0.0 1.3 1624 820 ? S 21:21 0:00 klogd
rpc 359 0.0 0.9 1468 576 ? S 21:21 0:00 portmap
root 375 0.0 0.0 0 0 ? SW 21:21 0:00 [lockd]
root 376 0.0 0.0 0 0 ? SW 21:21 0:00 [rpciod]
rpcuser 386 0.0 1.3 1572 824 ? S 21:21 0:00 rpc.statd
root 401 0.0 0.8 1308 524 ? S 21:21 0:00 /usr/sbin/apmd -p
455 0.0 0.9 1356 576 ?
S 21:21 0:00 /usr/sbin/atd
Network daemons are bound to
a particular port and listen for connection requests.
A listing of service/port mappings
are found in the file /etc/services .
There are a few utilities in UNIX which allow a user to view which ports are “open”.
to find open ports
netstat --inet --all (Linux, show network ports)
netstat -f inet
(Solaris, Digital Unix)
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:www *:* LISTEN
tcp 0 0 *:1024 *:* LISTEN
tcp 0 0 *:sunrpc *:* LISTEN
udp 0 96 laptop.oit:1034 nic.umass.edu:domain
udp 0 0 laptop.oit:1034 nic.umass.edu:domain
udp 0 0 *:1027 *:*
udp 0 0 *:986 *:*
udp 0 0 *:1026 *:*
udp 0 0 *:sunrpc *:*
udp 0 0 *:1025 *:*
udp 0 0 *:sunrpc *:*
udp 0 0 *:1025 *:*
0 0 *:1024
Using lsof to
find open ports
The utility lsof (“list open files”) can list network ports along with the listening process.
lsof -i tcp
(list all tcp ports)
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
portmap 359 root 4u IPv4 423 TCP *:sunrpc (LISTEN)
rpc.statd 386 root 7u IPv4 463 TCP *:1024 (LISTEN)
httpd 1021 root 16u IPv4 16531 TCP *:www (LISTEN)
httpd 1022 root 16u IPv4 16531 TCP *:www (LISTEN)
httpd 1023 root 16u IPv4 16531 TCP *:www (LISTEN)
httpd 1024 root 16u IPv4 16531 TCP *:www (LISTEN)
httpd 1025 root 16u IPv4 16531 TCP *:www (LISTEN)
root 16u IPv4 16531
TCP *:www (LISTEN)
Using nmap to
find open ports
nmap is an extremely versatile port scanning tool.
Using the command “nmap -sT laptop.oit.umass.edu”
Starting nmap V. 2.53 by firstname.lastname@example.org
Interesting ports on laptop.oit.umass.edu (128.119.xxx.xxx):
(The 1519 ports scanned but not shown below are in state: closed)
Port State Service
80/tcp open http
111/tcp open sunrpc
1024/tcp open kdm
6000/tcp open X11