Unit 2: Permissions, Processes, Services, SSH, and Logs

CSE493 — Linux System Administration 7 min read

I. Orientation

Linux administration is organized around controlled access, running processes, managed services, remote administration, and recorded system activity. These mechanisms are connected: permissions protect files, processes perform work, services supervise long-running processes, SSH provides controlled remote access, and logs preserve evidence of system behavior.

  • Users and groups: Every process has a user identity and group memberships that influence access decisions.
  • Objects and resources: Files, directories, devices, sockets, and processes are protected or managed as system resources.
  • Least privilege: Users and services should receive only the permissions required for their tasks.
  • Process model: The kernel assigns each process a process identification number, or PID, and tracks its state.
  • Service model: On systemd systems, unit files define how services start, stop, restart, and depend on other units.
  • Auditability: Syslog files and the systemd journal record events with timestamps, priorities, facilities, and source information.
  • Time accuracy: Correct time is essential because log ordering, authentication, certificates, and scheduled jobs depend on it.

II. Linux File System Permissions — Access Control Fundamentals

Permissions determine which users may read, modify, or execute filesystem objects.

A. Controlling Access to Files with Linux File System Permissions

This topic explains the kernel’s basic access decision for an object.

  • Ownership classes: Permissions are evaluated for the owning user, the owning group, or everyone else; these are represented by u, g, and o.
  • Permission meanings: For a regular file, r reads contents, w changes contents, and x runs the file as a program.
  • Directory meanings: On a directory, r lists names, w creates or removes entries, and x permits traversal; deleting a file primarily requires directory write and execute permission.
  • Access selection: The kernel uses the most specific matching class, so a user who owns a file does not also receive the group class permissions.
  • Special controls: Set-user-ID, set-group-ID, and sticky-bit modes alter execution or directory behavior; /tmp commonly uses mode 1777, allowing shared creation while restricting deletion.

B. Linux File System Permissions

Linux stores permission bits with metadata such as owner, group, size, and timestamps.

  • Symbolic display: ls -l report.txt may show -rw-r-----, where the first character identifies the file type and the next nine characters represent three permission triplets.
  • Numeric mode: r=4, w=2, and x=1; therefore 640 means owner rw-, group r--, and others ---.
  • Default ownership: A newly created file normally belongs to the creating user and that user’s current group, subject to directory and filesystem rules.
  • Permission limits: Traditional mode bits cannot express every policy; POSIX ACLs, displayed with getfacl, provide additional named-user or named-group entries.

III. Managing File System Permissions — Command-Line Administration

Command-line tools provide repeatable ways to inspect and change ownership and modes.

A. Managing File System Permissions from the Command Line

This topic covers chmod, chown, and related inspection commands.

  • Changing mode numerically:
    BASH
      chmod 640 report.txt

    640 gives the owner read/write, the group read, and others no access.
  • Changing mode symbolically: chmod g+w script.sh adds group write permission; chmod o-r secret removes read permission from others.
  • Changing ownership: chown alice:developers project.txt sets user alice and group developers; changing ownership generally requires root privileges.
  • Recursive changes: chmod -R and chown -R affect descendants, but applying one mode indiscriminately can make directories unusable or expose private files.
  • Inspection: stat file, ls -ld directory, and namei -l /path/to/file reveal metadata and permissions along a path.

B. Managing Default Permissions and File Access

Default permissions control how newly created files and directories begin.

  • umask calculation: The process umask removes permission bits from requested defaults. With umask 027, a requested 666 file becomes 640, while a requested 777 directory becomes 750.
  • File versus directory defaults: Programs commonly request 0666 for files and 0777 for directories; files do not receive execute permission merely because of umask behavior.
  • Setting a mask:
    BASH
      umask 027

    Shell startup files or service definitions can make this setting persistent.
  • Access checks: A pathname requires execute permission on every parent directory; a file’s mode alone does not guarantee access.
  • ACL inheritance: setfacl -m d:g:developers:rwx shared/ creates a default ACL for newly created entries under shared/.

IV. Linux Processes — Running Work and Job Control

A process is an executing program with memory, open files, credentials, and a kernel-managed PID.

A. Monitoring and Managing Linux Processes

Process administration combines observation, priority control, and termination.

  • Process hierarchy: Each process has a parent PID, or PPID; pstree displays relationships, while PID 1 is the system’s initial service manager.
  • Resource priority: Niceness influences CPU scheduling; nice -n 10 command starts a less favored process, and renice changes an existing process.
  • Foreground and background: A shell can start work asynchronously with command &, allowing the prompt to return.
  • Ownership limits: Ordinary users may usually manage their own processes; changing another user’s process or priority often requires root privileges.
  • Process states: Common states include running, sleeping, stopped, and zombie; a zombie has exited but awaits collection by its parent.

B. Processes

This topic focuses on process identity, state, and lifecycle.

  • PID identity: $$ expands to the current shell’s PID; $PPID identifies its parent shell or process.
  • Creation: A shell typically creates a child through fork() and then loads a program with an exec()-family call.
  • Exit status: A completed command returns a numeric status in $?; zero conventionally indicates success.
  • Daemon behavior: A daemon usually runs without an interactive terminal, listens for requests, and is supervised by a service manager.
  • Zombie diagnosis: ps -eo pid,ppid,stat,cmd shows Z in the STAT field for zombie processes; the parent must reap the child.

C. Controlling Jobs

Shell job control manages processes attached to the current terminal.

  • Listing jobs: jobs -l shows job numbers, PIDs, and states such as Running or Stopped.
  • Stopping and resuming: Ctrl+Z sends a terminal stop signal; bg %1 resumes job 1 in the background, and fg %1 returns it to the foreground.
  • Detaching work: nohup command >output.log 2>&1 & protects a command from terminal hangup, although systemd-run or a service is generally better for long-running work.
  • Job identifiers: %1 is a shell job number, whereas 1234 is a PID; commands such as kill normally use the PID.

D. Killing Processes

Signals request or force a process to change state.

  • Graceful termination: kill 1234 sends SIGTERM (15), allowing cleanup; applications should handle it where possible.
  • Forced termination: kill -KILL 1234 sends SIGKILL (9), which the process cannot catch or ignore; it should be a last resort.
  • Signal inspection: kill -l lists signal names; pkill -u alice targets processes by user and must be used carefully.
  • Service distinction: For a systemd-managed process, systemctl stop name.service updates the service’s intended state instead of killing only one process.

E. Monitoring Process Activity

Activity monitoring identifies CPU, memory, I/O, and process-state problems.

  • Snapshot view: ps aux gives a point-in-time listing; %CPU, %MEM, VSZ, RSS, and STAT summarize resource and state information.
  • Live view: top refreshes process data interactively; htop provides a more navigable interface when installed.
  • Load interpretation: The load average estimates runnable or uninterruptible work over 1, 5, and 15 minutes; compare it with available CPU cores.
  • Open resources: lsof -p 1234 lists files, sockets, and pipes held