\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: