--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/coursework/so04.tex Fri Oct 27 23:57:21 2017 +0100
@@ -0,0 +1,365 @@
+\documentclass{article}
+\usepackage{../style}
+\usepackage{../langs}
+
+\begin{document}
+
+\section*{Hints for Coursework}
+
+\begin{flushright}
+\it ``I have no special talents.\\
+I am only passionately curious.''\\
+\small--- Albert Einstein
+\end{flushright}\medskip
+
+\noindent Many students seem to have some difficulties with this coursework.
+While it can be solved with just logical
+reasoning, this seems to me like learning swimming on dry land.
+Why not trying out what an actual UNIX system has to say?
+Seems obvious isn't it? ;o)
+
+\subsection*{Environment}
+
+I know at least three ways of how to set up a testing
+environment without affecting my main computer, and which
+should work regardless of whether you have a Windows, MacOSX
+or Linux machine:
+
+\begin{enumerate}
+\item You can download Oracle's VirtualBox
+
+\begin{center}
+\url{https://www.virtualbox.org}
+\end{center}
+
+ There are binaries for Windows and MacOSX (I only tried
+ out MacOSX). In addition, you need to download a Linux
+ distribution. I used a recent iso-file of an Ubuntu
+ distribution. All components are free.
+
+\item If you happen to have a Raspberry Pi laying around (I
+ have two for playing music as well as for all sorts of
+ rainy-afternoon distractions). The cheapest model of a
+ Raspberry Pi costs around \pounds{7}. More expensive
+ versions cost around \pounds{20}.
+ You also need an
+ SD memory card of at least 4GB, which can be bought for
+ \pounds{5} or less. Some SD cards come pre-installed
+ with Linux, but all can be easily loaded with Linux. The
+ good thing about Raspberry Pi's is that despite their
+ miniature size and small cost, they are full-fledged
+ Linux computers\ldots{}exactly what is needed for such
+ experiments. There are plenty Linux distributions on the
+ Net that are tailored to work ``out of the box'' with
+ Raspberry Pi's.
+
+\item If you have a spare memory stick laying
+ around, you can try out any of the live USB-versions
+ of Linux.
+
+ \begin{center}
+ \url{https://en.wikipedia.org/wiki/Live_USB}
+ \end{center}
+
+ The idea is to upload Linux on the USB stick, you plug
+ it into your computer and boot up a Linux system without
+ having to download anything to your computer. A notable
+ live USB version of Linux is called Tails
+
+ \begin{center}
+ \url{https://tails.boum.org}
+ \end{center}
+
+ which comes with Tor pre-installed and is for people who
+ need a maximum of privacy and anonymity (whistleblowers,
+ dissidents). It is being said that journalists Laura
+ Poitras and Glenn Greenwald used it when talking to
+ Edward Snowden. Tails gives them anonymity even if their
+ main system is compromised by malicious software, for
+ example installed by the NSA.
+
+ However, a live USB Linux will need some support from
+ the computer (BIOS) where you plug in the USB stick. I
+ know Apple computers are a bit ``special'' with this and
+ would need a 3rd-party boot loader for loading operating
+ systems from an USB memory stick.
+
+ An alternative is to burn a CD/DVD with a live Linux
+ distribution. But perhaps CDs/DVDs are already obsolete
+ technology not available to everyone. The point is that
+ loading an operating system from such a media is/was
+ much better supported by various computers.
+
+\end{enumerate}
+
+\noindent For my experiments below, I used option 2. In
+earlier versions of this module I have used option 1. I have
+not tried in a while option 3, but know that in the past I had
+a dedicated bootloader on an Apple computer just for the
+purpose of running operating systems from external disks. I
+also for a long time had spare CDs laying around just for the
+purpose that my (Linux) operating system got trashed enough so
+that it had to be rebooted externally.
+
+\subsection*{Setup}
+
+Once you have Linux up and running, there are a few commands
+you need to know in order to replicate the ownerships and
+permissions from the question:
+
+\begin{itemize}
+\item \texttt{useradd} creates a new user
+\item \texttt{groupadd} creates a new group
+\item \texttt{adduser} adds a user to a group
+\item \texttt{chmod} changes the permissions of a file
+\item \texttt{chown}, \texttt{chgrp} change the ownership and
+group of a file
+\end{itemize}
+
+\noindent There is also a choice to be made what to use as
+microedit. If you do not want to make your hands dirty and
+write a test program yourself, I recommended to use the
+editors \texttt{vi} or \texttt{vim}, which is available on
+pretty much every UNIX system. For a first try out, this is a
+helpful choice for solving the question. However, it has a
+disadvantage: it will always assume you have read permissions
+to a file. To use these editors, I made a copy of them
+and renamed them to \texttt{microedit}. Be careful to set the
+setuid bit for \texttt{microedit}.
+
+
+\subsection*{Permission Basics}
+
+The absolute basics is how the permissions are organised
+in essentially four blocks
+
+\begin{center}
+${\underbrace{\huge\texttt{-}}_{\text{\makebox[0mm]{directory}}}}
+ {\underbrace{\huge\texttt{-{}-{}-}}_{\text{user}}}\,
+ {\underbrace{\huge\texttt{-{}-{}-}}_{\text{group}}}\,
+ {\underbrace{\huge\texttt{-{}-{}-}}_{\text{other}}}$
+\end{center}
+
+\noindent This seems to be the knowledge everybody has. But
+already difficulties arise with the following fact, which
+could easily be resolved by a little experiment: assume a file
+is owned by Bob with permissions
+
+\begin{center}
+$\texttt{-{}r-{}-{}rw-{}rwx\;\;bob\;students\;\;file\_name}$
+\end{center}
+
+\noindent The UNIX access rules imply that Bob will only have
+read access to this file, even if he is in the group students
+and the group access permissions allow read and write.
+Similarly every member in the students group who is not Bob,
+will only have read-write access permissions, not
+read-write-execute.
+
+The question asked whether Ping, Bob and Emma can read or write
+the given files \underline{\smash{using}} the program
+microedit. This means we will call on the command line
+
+\begin{center}
+$\texttt{>}\;\;\texttt{microedit}\;\textit{file\_name}$
+\end{center}
+
+\noindent for all files and for Bob, Ping and Emma. So if you
+want to find out whether Bob, say, can read or write a file,
+you need to find out what the access permissions with which
+\texttt{microedit} is run. This would be easy, if
+\texttt{microedit} did not have the setuid bit set. Then it
+would be just the rights of the caller (Ping, Bob or Emma).
+But your friendly lecturer arranged the question so that it
+has the setuid bit.
+
+Recall that the setuid bit gives the program the ability to
+run with the permissions of the owner \texttt{microedit}
+file, not the permissions of the caller. I wrote in the
+handout
+
+\begin{quote}\it
+``The fundamental idea behind the setuid attribute is that a
+file will be able to run not with the callers access rights,
+but with the rights of the owner of the file.''
+\end{quote}
+
+\noindent Something similar is written in the Wikipedia
+entry for setuid
+
+\begin{center}
+\url{http://en.wikipedia.org/wiki/Setuid}
+\end{center}
+
+\noindent This implies for deciding whether \textit{file} is
+readable or writable is not determined by the caller, but by
+the permissions with which \texttt{microedit} runs. As you
+might know already, and can also see in the Figure~\ref{test}
+shown later, any \textit{file\_name} given on the command line
+will be handed over to microedit as string. It is the
+``responsibility'' of \texttt{microedit} what to do with it.
+
+
+There is one caveat however: We need to find out first whether
+the caller (Bob, Ping or Emma) can actually run
+\texttt{microedit}---that is has execute permissions for
+\texttt{microedit}. Once \texttt{microedit} runs, it will
+assume the permissions of the owner of \texttt{microedit}. The
+question is now whether these permissions are sufficient to
+read or write the file \textit{file\_name}. The hints so far
+should already be useful for answering the first three
+columns.
+
+For the other two files we have to take into account that they
+are inside a directory. For directories apply special access
+rules. In the handout I wrote
+
+\begin{quote}\it
+``There are already some special rules for directories and
+links. If the execute attribute of a directory is \emph{not}
+set, then one cannot change into the directory and one cannot
+access any file inside it. If the write attribute is
+\emph{not} set, then one can change existing files (provide
+they are changeable), but one cannot create new files. If the
+read attribute is \emph{not} set, one cannot search inside the
+directory (\texttt{ls -la} does not work) but one can access an
+existing file, provided one knows its name.''
+\end{quote}
+
+\noindent With this also the last two columns can be filled
+in.
+
+% \subsection*{Advanced Permissions}
+
+% While all hints so far should get you very close to the
+% intended answers, there is one further complication arising
+% from the setuid bit. The question asked:
+
+% \begin{quote}\it
+% \ldots{}whether Ping, Bob, or Emma \underline{are able} to obtain
+% the right to read (R) or replace (W) its contents using
+% the editor microedit.
+% \end{quote}
+
+% \noindent Note the underlined phrase. That means we need to
+% ensure that there is no other way for Bob, Ping and Emma to
+% obtain reading or writing permissions with \texttt{microedit}.
+% Actually there is. Any file that has the setuid bit set will
+% be called with the permissions of the owner, but once it has done
+% the work, it can ``lower'' the permissions again to the
+% callers rights. This is a second possibility we have to check
+% whether the files become readable or writable when the
+% permissions of the caller are re-instated. In the handout
+% I wrote about the setuid-program \texttt{passwd}:
+
+% \begin{quote}\it
+% ``As an example consider again the \texttt{passwd}
+% program. When started by, say the user \texttt{foo}, it has at
+% the beginning the identities:
+
+% \begin{itemize}
+% \item \emph{real identity}: \texttt{foo}\\
+% \emph{effective identity}: \texttt{foo}\\
+% \emph{saved identity}: \texttt{root}
+% \end{itemize}
+
+% \noindent It is then allowed to change the effective
+% identity to the saved identity to have
+
+% \begin{itemize}
+% \item \emph{real identity}: \texttt{foo}\\
+% \emph{effective identity}: \texttt{root}\\
+% \emph{saved identity}: \texttt{root}
+% \end{itemize}
+
+% \noindent It can now read and write the file
+% \texttt{/etc/passwd}. After finishing the job it is supposed to
+% drop the effective identity back to \texttt{foo}. This is the
+% responsibility of the programmers who wrote \texttt{passwd}.
+% Notice that the effective identity is not automatically
+% elevated to \texttt{root}, but the program itself must make
+% this change. After it has done the work, the effective
+% identity should go back to the real identity.
+% ''
+% \end{quote}
+
+% \noindent It was hoped by your friendly lecturer that any of
+% the students would have consciously considered this
+% possibility, but alas nobody did\ldots{}
+
+\subsection*{A Program in C}
+
+I suggested above to use a copy of the editors \texttt{vm} or
+\texttt{vim} for \texttt{microedit}. This works reasonably
+well, except for one instance: if a file is not readable, then
+these editors will not be helpful for checking whether the
+file is writable. Giving out such a permission is a perfectly
+``normal'' situation in many large UNIX systems. A user might
+be allowed to write into central log files, but should not be
+able to read them (otherwise they can find out what other
+users did). To get around this problem, I brushed up my C
+knowledge from school days and googled around for how to read
+and write files. Typing in ``read write in C'' in the
+all-knowing search engine, I obtained the link
+
+\begin{center}
+\url{https://www.cs.bu.edu/teaching/c/file-io/intro/}
+\end{center}
+
+\noindent which tells you pretty much everything what there is
+about opening a file in C for reading and writing. (There are
+certainly more and better sources for finding out how to read
+and write files. This was just at my finger tips.) A little
+bit more googling helped me to display the user that
+determines the access permissions. Being lazy, I did not spend
+a thought of refactoring the file to be as small as possible,
+and also did not go the extra mile to convert the ID of the
+user into a clear name.
+
+The resulting little C program is shown in Figure~\ref{test}.
+It explicitly checks for readability and writability of files.
+The \pcode{main} function is organised into two parts: the
+first checks readability and writability with the permissions
+according to a potential setuid bit, and the second (starting
+in Line 34) when the permissions are lowered to the caller.
+Note that this program has one problem as well: it only gives
+a reliable answer in cases a file is {\bf not} readable or
+{\bf not} writable. In these cases it returns an error code 13
+(permission denied). It sometimes claims a file is not
+writable, say, but with an error code 26 (text file busy).
+This is unrelated to the permissions of the file.
+
+\begin{figure}[t]
+\small\mbox{}\\[-14mm]
+\lstinputlisting[language=C]{../progs/read.c}\mbox{}\\[-13mm]
+\caption{A read/write test program in C. It returns errno = 13
+in cases when permission is denied.\label{test}}
+\end{figure}
+
+%\subsection*{Solution}
+%
+%\begin{center}
+%\begin{tabular}{r|c|c|c|c|c}
+% & manual.txt & report.txt & microedit & src/code.c & src/code.h \\\hline
+%ping & R- & R- & RW & -- & --\\\hline
+%bob & R- & R- & RW & -- & --\\\hline
+%emma & -- & -- & -- & -- & --\\
+%\end{tabular}
+%\end{center}
+%
+%\begin{center}
+%\begin{tabular}{r|c|c|c|c|c}
+% & manual.txt & report.txt & microedit & src/code.c & src/code.h \\\hline
+%ping & RW & -W & RW & R- & --\\\hline
+%bob & R- & R- & RW & -- & --\\\hline
+%emma & -- & -- & -- & -- & --\\
+%\end{tabular}
+%\end{center}
+
+
+\end{document}
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: t
+%%% End: