-<h2><A name="s-noexcess">
-6.3 Do not give away excessive privilege to <kbd>userv</kbd>-using facilities
-</A></h2>
-
-There is a danger that people reimplementing the facilities I mention
-above using <kbd>userv</kbd> will discard much of the security benefit by
-using a naive implementation technique. This will become clearer with
-an example:<P>
-
-Consider the <kbd>lpr</kbd> program. In current systems this needs to
-have an absolutely privileged component in order to support delayed
-printing without copying: when the user queues a file to be printed
-the filename is stored in the print queue, rather than a copy of it,
-and the printer daemon accesses the file directly when it is ready to
-print the job. In order that the user can print files which are not
-world-readable the daemon is given root privilege so that it can open
-the file in the context of the user, rather than its own.<P>
-
-A simple-minded approach to converting this scheme to use <kbd>userv</kbd>
-might involve giving the printer daemon (the <kbd>lp</kbd> user) the
-ability to read the file by allowing them to run <kbd>cat</kbd> (or a
-special-purpose file-reading program) as any user. The <kbd>lpr</kbd>
-program would use a <kbd>userv</kbd> service to store the filename in the
-printer daemon's queues, and the daemon would read the file later when
-it felt like it.<P>
-
-However, this would allow the printer daemon to read any file on the
-system, whether or not someone had asked for it to be printed. Since
-many files will contain passwords and other security-critical
-information this is nearly as bad as giving the daemon root access in
-the first place. Any security holes in the print server which allow a
-user to execute commands as the <kbd>lp</kbd> user will give the user the
-ability to read any file on the system.<P>
-
-Instead, it is necessary to keep a record of which files the daemon
-has been asked to print <em>outside</em> the control of the print daemon.
-This record could be kept by a new root-privileged component, but this
-is not necessary: the record of which files a user has asked to be
-printed can be kept under the control of the user in question. The
-submission program <kbd>lpr</kbd> will make a record in an area under the
-user's control before communicating with the print server, and the
-print server would be given the ability to run a special file-reading
-program which would only allow files to be read which were listed in
-the user's file of things they'd asked to print.<P>
-
-Now security holes in most of the printing system do not critically
-affect the security of the entire system: they only allow the attacker
-to read and interfere with print jobs. Bugs in the programs run by the
-print server to read users' files (and to remove entries from the list
-of files when it has done with them) will still be serious, but this
-program can be quite simple.<P>
-
-Similar considerations apply to many <kbd>userv</kbd>-based versions of
-facilities which currently run as root.<P>
-
-It is debatable whether the user-controlled state should be kept in
-the user's filespace (in dotfiles, say) or kept in a separate area set
-aside for the purpose; however, using the user's home directory (and
-probably creating a separate subdirectory of it as a dotfile to
-contain many subsystems' state) has fewer implications for the rest of
-the system and makes it entirely clear where the security boundaries
-lie.
+
+<a name="s-stdinerr"></a>
+<h2>6.6 Error handling and input streams (eg stdin)</h2>
+
+<p>
+When the service program is reading from a file descriptor connected to the
+calling side, the fd that the service program refers to a pipe set up by
+<code>userv</code> and not to the same object as was presented by the caller.
+
+<p>
+Therefore if there is some kind of error it is possible for the service-side fd
+to give premature end of file. If it is important to tell whether all of the
+intended data has been received by the service program, the datastream must
+contain an explicit end-of-file indication of some kind.
+
+<p>
+For example, consider a <code>userv</code> service for submitting a mail
+message, where message is supplied on the service's stdin. However, if the
+calling process is interrupted before it has written all of the message, the
+service program will get EOF on the message data. In a naive arrangement this
+would cause a half-complete message to be sent. To prevent this, it is
+necessary to adopt some kind of explicit end indication; for example, the end
+of the message could be signalled by a dot on a line by itself, and dots
+doubled, as in SMTP. Then the service program would know when the entire
+message had been received, and could avoid queueing incomplete messages.
+