--- a/handouts/ho04.tex	Tue Dec 30 01:22:25 2014 +0000
+++ b/handouts/ho04.tex	Tue Dec 30 21:59:47 2014 +0000
@@ -27,10 +27,31 @@
 access: \underline{\textbf{r}}ead, \underline{\textbf{w}}rite
 and e\underline{\textbf{x}}ecute. Moreover there are three
 user groups to which the modes apply: the owner of the file,
-the group the file is associated with and everybody else. This
-relatively fine granularity seems to cover many useful
-scenarios of access control. A typical example of some files
-with permission attributes is as follows:
+the group the file is associated with and everybody else. 
+A typical permission of a file owned by \texttt{bob} might look as 
+follows:
+
+\begin{center}
+${\underbrace{\LARGE\texttt{-}}_{\text{\makebox[0mm]{directory}}}}
+ \;{\underbrace{\LARGE\texttt{r{}-{}-}}_{\text{user}}}\,
+ {\underbrace{\LARGE\texttt{r{}w{}-}}_{\text{group}}}\,
+ {\underbrace{\LARGE\texttt{r{}w{}x}}_{\text{other}}}\;\;\;
+ \LARGE\texttt{bob}\;\;\;\texttt{staff}$
+\end{center}
+
+\noindent For the moment let us ignore the directory bit. The
+Unix access rules imply that Bob will only have read access to
+this file, even if he is in the group \texttt{staff} and the
+group access permissions allow read and write. Similarly every
+member in the \texttt{staff} group who is not \texttt{bob},
+will only have read-write access permissions, not
+read-write-execute.
+
+This
+relatively fine granularity of owner, group, everybody else
+seems to cover many useful scenarios of access control. A
+typical example of some files with permission attributes is as
+follows:
 
 {\small\lstinputlisting[language={}]{../slides/lst}}
 
@@ -158,18 +179,38 @@
 this change. After it has done the work, the effective
 identity should go back to the real identity.
 
+If you want to play more with access rights in Unix, you can
+use the program 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 when 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}[p]
+\small
+\lstinputlisting[language=C]{../progs/read.c}
+\caption{A read/write test program in C. It returns errno = 13 
+in cases when permission is denied.\label{test}}
+\end{figure}
 
 Despite this complicated semantics, Unix-style access control
 is of no use in a number of situations. For example it cannot
 be used to exclude some subset of people, but otherwise have
 files readable by everybody else (say you want to restrict
-access to a file such that your office mates cannot access 
-a file). You could try setting the group of the file to this
+access to a file such that your office mates cannot access a
+file). You could try setting the group of the file to this
 subset and then restrict access accordingly. But this does not
 help, because users can drop membership in groups. If one
 needs such fine-grained control over who can access a file,
-one needs more powerful \emph{mandatory access controls}
-as described next.
+one needs more powerful \emph{mandatory access controls} as
+described next.
 
 
 \subsubsection*{Secrecy and Integrity}