Operating Systems 2020W Lecture 7

Video

Video for the lecture given on January 29, 2020 is now available.

Notes

Topics

• Assignment 1
• Signals
• setuid
• login process

(others moved to Friday)

In Class

Lecture 7
---------

UNIX signals
 - messages received by a process, sent by another process or the kernel
 - used to pause or terminate process, and to report error conditions
   (memory access errors, divide by zero, etc)

 - you can send signals using the kill command (which makes a kill system call)
   - by default, sends SIGTERM

 - sorry for no subtitles, will try to set up soon.  Also will see if zoom
   helps with audio

 - can send any signal with kill, that's what it is for
   - but what they do depends on who you are, what privileges you have
   - is the way you send a signal

 - for example, regular users can't terminate processes running as other
   users (can't send SIGTERM or SIGKILL)
   - the root user can terminate any process (send signals to all processes)

 - signal handlers are a bit weird
   - regular functions, but...
   - they can run at any time
   - they are called directly by the kernel
   - they pause regular execution (which resumes after the signal handler
     finishes)

 - the C library registers default signal handlers
   - they mostly just terminate the process when a signal is received
 - you can register your own for *most* signals
   - except SIGKILL and SIGSTOP  ("force quit" and pause/stop)
     so you can't change what happens with them

   - but the rest, you can control by registering a signal handler for
     that signal.  Afterwards, your code will be called when your process
     receives that signal
      - your signal handler can ignore the signal
      - thus, for SIGSEGV, you can just ignore and have your program continue

   - if you want to send a signal for an application-specific purpose,
     use SIGUSR1 and SIGUSR2, that is what they are there for
   - you cannot define your own signals, they are defined by the kernel

 - signals introduce a weird form of concurrency in single-threaded UNIX
   processes
     - signal handlers can be called at any time, pausing whatever is currently
       going on
     - so if a signal handler modifies shared data structures or state
       it can corrupt ongoing work
     - basic rule: make sure signal handlers do as little as possible
       and don't interfere
     - even printing things out isn't recommended from a signal handler
       (that's I/O)

 - if signals can happen at anytime, that means they can also happen
   while a process is doing a system call
 - so, what happens to the system call?
     - option 1: system call is cancelled, returns an error
     - option 2: system call is paused then resumed
     - option 3: system call completes *then* signal handler is run
 - in reality, 1 or 3 is what happens, but sometimes we simulate 2
     - simulated by setting SA_RESTART option in sigaction
     - (this is the default behavior on BSD systems)
     - means a read or sleep will continue even if interrupted by a signal
        - signal handler runs
        - system call returns with error saying it was interrupted by a signal
        - library code calls system call again
 - for example, consider sleep and read (say for terminal input)
     - interrupted by signals, cause signal handler to be run
       then system call returns immediately (before sleep has finished
       or data has been read)
 - running a signal handler is an old fashioned way of handling an exception
     - before there were exceptions, there were signals
     - low-level exceptions are based on signals (e.g., divide by zero)

 - (and yes they kind of look like hardware interrupts, they are pure software
    but design is like interrupt handlers)

 - signals are relatively lightweight as far as IPC goes
     - but don't use them for performance-critical tasks, other
       mechanisms are much safer and more reliable

 - signals are specialized, not a general mechanism

 
 - when you type some special characters into a terminal they generate
   (by default) signals
     Ctrl-C generates SIGINT (I think)
     Ctrl-Z generates SIGSTOP

 - sigchld is sent to a process when a child process terminates
   - so parent doesn't have to call wait() and wait around, it
     can do its own thing and call wait() in a signal handler
     for SIGCHLD

 - all processes are listening to all signals
   - most just have default handlers defined by the C library
   - not quite sure what happens if you don't define a handler
     (e.g., if you bypass the C library)

 - when any process terminates, its parent must call wait to
   get its return value (otherwise it turns into a zombie)
 - if the parent goes away, there is always the parent of last resort:
   init (PID 1)
 - init always calls wait in response to SIGCHLD
 - if init terminates, the system shuts down

 - on modern Linux systems, init is part of systemd

 - a zombie process is a process that has terminated but who hasn't
   been reaped (waited on by its parent)
     - it still shows up in the process table with status "Z"
     - it can't be killed
     - can only be eliminated by killing the irresponsible parent
       - then init will take over and run wait
 

3000login
 - Q: what happens when you "log in" to a UNIX system?

 - first, have to authenticate (type in your password, do public key based
   auth, show your face, whatever)

 - after authentication, have to start the user's session.  How?

 - to a first approximation, it is just like running a command in a shell
   - except that first "command" has to run as a specific user

Code

download 3000login.c

/* 3000login.c */
/* version 0.1 */

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>

int main(int argc, char *argv[], char *envp[])
{
        uid_t uid;
        int result;
        char *bash_argv[3];
        
        if (argc < 2) {
                fprintf(stderr, "Usage: %s <user ID>\n", argv[0]);
                exit(-1);
        }

        uid = atoi(argv[1]);

        result = setuid(uid);

        if (result == 0) {
                fprintf(stderr, "Successfully changed to uid %d\n", uid);
                bash_argv[0] = "bash";
                bash_argv[1] = "--login";
                bash_argv[2] = NULL;
                execve("/bin/bash", bash_argv, envp);
        } else {
                fprintf(stderr, "Failed to change to uid %d\n", uid);
                exit(-2);
        }

        fprintf(stderr, "Failed to exec bash\n");
        return -3;
}