Unix/Linux System and Network Fundamentals
This domain tests the Unix model that every network service depends on: processes, file descriptors, sockets, users, permissions, signals, and the kernel/user boundary. CUNP-style questions often ask why a daemon cannot bind a port, why a socket disappears when a process exits, or which identity a service actually runs as.
Core rules and concepts
- A process has its own address space; threads share one. Both are scheduled by the kernel, but only processes have separate PID and resource accounting.
- File descriptors are small integers in a per-process table. Sockets, pipes, and files are all descriptors; a child inherits open descriptors across fork unless close-on-exec is set.
- System calls cross into the kernel and return -1 with errno on failure. Programs must check both the return value and errno.
- Effective UID/GID determine permission checks; saved and real IDs affect setuid behavior. Capabilities such as CAP_NET_BIND_SERVICE can grant a narrow privilege without full root.
- Signals are asynchronous notifications. SIGTERM requests termination, SIGKILL cannot be caught, and SIGHUP often means reload by convention, not by kernel rule.
- Daemons should detach from the terminal, close unneeded descriptors, set a working directory, and log through syslog or the journal.
Worked example
A web server run as user www-data fails with permission denied when binding TCP port 80. Check the effective identity and the listen attempt with ss or strace. Ports below 1024 traditionally require privilege. The correct fixes are to start through a supervisor that grants CAP_NET_BIND_SERVICE, to use a reverse proxy on port 80, or to lower net.ipv4.ip_unprivileged_port_start only with a deliberate security decision. Running chmod 777 on the binary is not a fix; it changes file access, not the bind privilege.
Traps that cost marks
Do not confuse a process with a thread, root with a capability, or file permissions with network permissions. Remember that a listening socket is an open descriptor, so inheritance and close-on-exec matter. Check the actual listening address, not only /etc/services, because that file maps names to ports but does not prove what is running.
Exam focus
Trace from the service identity to the socket, then to the kernel error. Use ps, ss, lsof, strace, and journalctl as evidence rather than guessing.