\documentclass{article}
\usepackage{../style}
\usepackage{../langs}

\begin{document}

\section*{Hints for Solving the 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: