My-Tiny.Net :: Networking with Virtual Machines



Key Concepts - System Accounts, Sticky Bit


The first purpose of system accounts is file permissions and ownership. For example, if a file has owner nobody and group nobody, and permissions are 660 (rw-rw----) only the application running as nobody and root can read or write the file.

Take a look at /etc/passwd and /etc/group. These are the master lists, and for historical reasons need to be world readable; encrypted passwords for users and groups are stored in /etc/shadow and /etc/gshadow to keep them secure. You can see that there are a number of system accounts defined for specific applications in these files already: ftp, sshd, mysql for example; the nobody user and group are used by our webserver.

By convention, User IDs from 0 to 99 are statically allocated by the system, and User IDs from 100 to 499 are reserved for dynamic allocation by system administrators and post install scripts using useradd. Similarly, Group IDs of less than 500 are reserved for user IDs employed by the operating system or its services.

Each field in a passwd entry is separated with ":" colon characters, and are as follows:
  1. Username: Case-sensitive, usually all lowercase
  2. An "x" in the password field: Passwords are stored in /etc/shadow
  3. Numeric user id: Unix uses this field, plus the following group field, to identify which files and processes belong to the user
  4. Numeric group ID: On many systems the group id will match the user id
  5. Info (GECOS): typically used to record general information about the account or its user(s) such as their real name and phone number. The name comes from ancient history (computerwise): the General Electric Comprehensive Operating Supervisor dates back to 1962, and some early Unix systems at Bell Labs used GECOS machines for print spooling and various other services, so this field was added to carry information on a user's GECOS identity
  6. Home directory: Usually /home/username (e.g., /home/bjensen). All user's personal files, web pages, mail forwarding, etc. should be stored here.
  7. Shell: Often set to /bin/bash to provide access to the bash shell.
As with the passwd file, each field in the shadow file is also separated with ":" colon characters, and are as follows:
  1. A direct match to the username in the /etc/passwd file.
  2. Encrypted password. A blank entry (::) indicates a password is not required to log in (usually a bad idea), and a * entry (:*:) indicates the account has been disabled.
  3. The number of days (since January 1, 1970) since the password was last changed.
  4. The number of days before password may be changed (0 indicates it may be changed at any time) i.e. the number of days left before the user is allowed to change his/her password
  5. The number of days after which password must be changed (99999 indicates user can keep his or her password unchanged for many, many years) after that the user is forced to change his/her password
  6. The number of days to warn user of an expiring password (7 for a full week)
  7. The number of days after password expires that account is disabled
  8. The number of days since January 1, 1970 that an account has been disabled i.e. an absolute date specifying when the login may no longer be used
  9. A reserved field for possible future use

Privileged Ports

The second purpose of system accounts is access to "privileged ports".

A port is an application-specific or process-specific software construct serving as a communications endpoint and it is identified by its number. A port number is a 16-bit unsigned integer, thus ranging from 0 to 65535. A process associates its input and output channel file descriptors with a port number and an IP address. This is known as binding. We saw an example when we retrieved a web page using this form of URL:
http://127.0.0.1:port/Index.html

Common services such as web, mail, imap etc. all use use specifically reserved, well-known port numbers for receiving service requests from client hosts. The well-known ports are defined by the Internet Assigned Numbers Authority (IANA) and listed on the local machine in /etc/services. Since it is presently the policy of IANA to assign a single well-known port number for both TCP and UDP, most of the assignments there have two entries even if the protocol doesn't support UDP operations.

IANA [RFC6335] has divided port numbers into three ranges or classes:
  • The Well Known Ports are those from 0 through 1023.
  • The Registered Ports are those from 1024 through 49151
  • The Dynamic and/or Private Ports are those from 49152 through 65535
For the list of current port assignments, check the IANA
Service Name and Transport Protocol Port Number Registry

Under UNIX and Linux, super user (root) privileges are required to open port numbers less than 1024, which is why these ports are known as "privileged ports". Typically clients use a port number from the dynamic/private range, but in order for the client to contact a server and request a service, the port for a service on a server needs to be predictable (well-known).

So, the way it is done is to start the server as root and drop privileges by switching process ownership to a system account after it's started listening on the privileged port.

The Sticky Bit

With the dovecot deliver LDA you have to make /home/vmail world-writeable with sticky bit set (same as /tmp). That is: wide open, except that only the owner of a file can rename or remove it.

Turns out there is one more bit used for permissions, which is shown as t in drwxrwxrwt when we look at them; or 1777 as normal for /tmp.

On a directory, the setting the sticky bit prevents anyone except the owner from renaming, moving or deleting files, even if they have write permission to the directory. Only the directory owner and superuser are exempt from this.

The sticky bit was introduced in the Fifth Edition of Unix (in 1974) for use with pure executable files. When set, it instructed the operating system to retain the text segment of the program in swap space after the process exited. This speeds up subsequent executions by allowing the kernel to make a single operation of moving the program from swap to real memory. Setting the sticky bit on a file is rare now, and usually will have no effect; but this explains why we see it as t in the permissions list.

Actually, there are two additional permission bits: 

     04000 Set user ID on execution (setuid)
     02000 Set group ID on execution (setgid)
     01000 Sticky bit

     so, 3777 sets both the setgid bit and the sticky bit
When a file with setuid is executed, the resulting process will assume the effective user ID of the file owner, so the user running the process temporarily has these privileges. The setuid permission on a directory is ignored on UNIX and Linux systems.

When a file with setgid is executed, the resulting process will assume the group ID of the owner. When the setgid bit is set on a directory all files (or directories) created in that directory will belong to the group that owns the directory, so group members do not have to explicitly change their current group before creating new files or directories.

To see a list of all the files and directories with Sticky Bit bit set, use find / -perm /1000