thesis: much more on linux process isolation

src/docs/glossary.tex

@@ -1,5 +1,12 @@
 % // vim: set ft=tex:
 
+\newglossaryentry{API}{
+    name = API,
+    description = {
+        Application Programming Interface
+    },
+}
+
 \newglossaryentry{OS}{
     name = Operating System,
     description = {
@@ -59,6 +66,20 @@
     plural=Linuces
 }
 
+\newglossaryentry{lxns}{
+    name = Linux Namespace,
+    description = {
+        entitiy that holds a specific set of process attributes and can be set per process
+    },
+}
+
+\newglossaryentry{lxcaps}{
+    name = Linux Capabilities,
+    description = {
+        entitiy that holds a specific set of process attributes and can be set per process, mainly to establish a relationship between processes and \gls{OS} resources
+    },
+}
+
 \newglossaryentry{BSD}{
     name = BSD,
     description = {

src/docs/parts/context/context.tex

@@ -85,30 +85,73 @@ As an example, when a process changes its root \gls{fs} to \textit{/newroot} and
 Note that \textit{chroot} has not been designed as a security feature, and therefore privileged \textit{chroot}'ed applications can easily access the host's filesystem if no countermeasures are taken.
 
 \subsubsection{Namespaces}
-% TODO explain namespaces in general
-% TODO uts
-% TODO pid
-% TODO mount
-% TODO net
-% TODO ipc
-% TODO cgroup
-% TODO user
+\Glspl{lxns} were designed in 2007 and described as lightweight in-kernel virtualization/isolation\cite{Menage2007}.
+The authors chose to invent a new name instead of using the descriptive term in order to clarify the distinction from the more heavyweight technology of \gls{VM} \glspl{hypervisor}.
+The various \Glspl{lxns} all represent different attributes related to the process and resource model on \gls{Linux}.
+Each namespace can contain one or more processes, allowing for arbitrary grouping of processes sharing.
+Table \ref{tab:lxns} shows 7 different \Glspl{lxns} that are available at the time of writing. 
+Collectively, they represent the context of a process, and changes to resources within the respective namespace will only affect processes that share the same namespace.
+
+\ctable[
+    cap = \Glspl{lxns},
+    caption = \Glspl{lxns}\footnote{from \textit{NAMESPACES(7)} and \textit{UNSHARE(2)}},
+    maxwidth = \textwidth,
+    label = tab:lxns
+    ]{l | X}{}{
+\FL
+    Namespace & Resources
+\ML
+    UTS &
+    Hostname, NIS domain name
+\NN
+    PID & 
+    Process IDs (each namespace will start counting from 1)
+\NN
+    Network &
+    Complete network stack:
+    Network interfaces, addresses, sockets, ports, routes, filter rules, \textit{/proc/net} and \textit{/sys/class/net}
+\NN
+    IPC &
+    System V/POSIX message queues, semaphore sets, shared memory segments
+\NN
+    Cgroup &
+    cgroup root directory \textit{/proc/self/cgroup}
+\NN
+    User & 
+    UIDs, GIDs, capabilities
+\NN
+    Mount &
+    Mount points, /proc/self/mountinfo
+}
+
+\subsubsection{Capabilities}
+% TODO
 
 \subsubsection{Control Groups}
 % TODO
  
 \subsubsection{Security Modules}
-% TODO explain what LSM is a framework
+% TODO explain that LSM is a framework
 % TODO AppArmor
 % TODO SELinux
 
+\subsubsection{Initialization And Combination Of The Above}
+When \gls{Linux} is booted, an initial set of namespaces, cgroups, and security contexts are created to contain the first userspace process, typically called init.
+
+Depending on the nature and configuration of the init process, other \glspl{app} are created with a new set of namespaces and cgroups, inherit all or only a selected set from the init process.
+The two concepts can be mingled since the mechanisms allow for a flexible configuration per process.
+This functionality is exposed via the \gls{Linux} systemcall \gls{API}.
+
+The systemcall \gls{API} can be used by any \gls{app} running as a privileged process, not only by the init process.
+Hence, any vendor or organization might create libraries and programs that make use of these functions, in order to provide lightweight virtualization functionality to other application developers, system administrators and end-users in an abstracted and easily usable fashion.
+
 \subsection{\Gls{fs} Storage Isolation And \Gls{app} Deployment}
 With the help of the different \ref{sect:linux-process-isolation} techniques ... TODO
 
 \subsection{\Gls{app} \Gls{virt}}
 % TODO compare app productivity and deployment by example of chroot vs VM
  
-\subsection{The Advent of \glspl{sac} with \gls{Docker}}
+\section{The Advent of \glspl{sac} with \gls{Docker}}
 \label{sect:virt-advent-sac}
 Even though the underlying technology \gls{osvirt} had been available for a relatively long time, \gls{Docker}\cite{Fink2014}, since its release in 2014\footnote{http://blog.docker.com/2014/06/its-here-docker-1-0}, has brought \glspl{sac} to the attention and hands of the masses in the \gls{OSS} community.
 From a psychological standpoint this is not surprising, as it has abstracted most complexities of the technology, adding ease of deployment, a platform for hosting the \gls{saci} in a Docker specific format, as well as a very convenient way for building the like using Dockerfiles(TODO reference).

src/docs/thesis.tex

@@ -8,7 +8,8 @@
 \usepackage{geometry}
 \geometry{a4paper, top=25mm, left=30mm, right=35mm,  bottom=35mm, headsep=10mm, footskip=12mm}
 
-\usepackage{multirow,tabularx,tabu}
+%\usepackage{multirow,tabularx,tabu}
+\usepackage{ctable,multirow}
 
 \usepackage{cite}
 \bibliographystyle{plain}