--- a/handouts/ho04.tex	Sun Oct 19 16:44:31 2014 +0100
+++ b/handouts/ho04.tex	Tue Oct 21 02:35:06 2014 +0100
@@ -11,7 +11,7 @@
 Access control is essentially about deciding whether to grant
 access to a resource or deny it. Sounds easy. No? Well it
 turns out that things are not as simple as they seem at first
-glance. Let us first look as a case-study at how access
+glance. Let us first look, as a case-study, at how access
 control is organised in Unix-like systems (Windows systems
 have similar access controls, although the details might be
 quite different).
@@ -103,14 +103,14 @@
 programmer.
 
 The fundamental idea behind the setuid attribute is that a
-file with this attribute will be able to run not with the
-callers access rights, but with the rights of the owner of the
-file. So \pcode{/usr/bin/login} will always be running with
-root access rights, no matter who invokes this program. The
-problem is that this entails a rather complicated semantics of
-what the identity of a process (that runs the program) is. One
-would hope there is only one such ID, but in fact Unix
-distinguishes three(!):
+file will be able to run not with the callers access rights,
+but with the rights of the owner of the file. So
+\pcode{/usr/bin/login} will always be running with root access
+rights, no matter who invokes this program. The problem is
+that this entails a rather complicated semantics of what the
+identity of a process (that runs the program) is. One would
+hope there is only one such ID, but in fact Unix distinguishes
+three(!):
 
 \begin{itemize}
 \item \emph{real identity}\\