-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<html>
<head>
+<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
+
<title>User service daemon and client specification - Applications and notes on use</title>
</head>
<body>
+<a name="ch-notes"></a>
<hr>
-[<a href="ch-ipass.html">back</a>]
- [<a href="index.html#abstract">Abstract</a>]
- [<a href="index.html#copyright">Copyright Notice</a>]
- [<a href="index.html#contents">Contents</a>]
+[ <a href="ch-ipass.html">previous</a> ]
+[ <a href="index.html#contents">Contents</a> ]
+[ <a href="ch-intro.html">1</a> ]
+[ <a href="ch-client.html">2</a> ]
+[ <a href="ch-envir.html">3</a> ]
+[ <a href="ch-config.html">4</a> ]
+[ <a href="ch-ipass.html">5</a> ]
+[ 6 ]
+[ <a href="index.html">next</a> ]
<hr>
<h1>
-User service daemon and client specification - Chapter 6<br>
-Applications and notes on use
+User service daemon and client specification
+<br>Chapter 6 - Applications and notes on use
</h1>
+
<hr>
-<h2>
-<a name="s-examples">6.1 Examples</a>
-</h2>
+<a name="s-examples"></a>
+<h2>6.1 Examples</h2>
<p>
The companion package, <code>userv-utils</code>, contains a selection of
-example services, some of which are useful tools in their own right.
-See the <code>README</code> in its top-level directory for details.
-</p>
+example services, some of which are useful tools in their own right. See the
+<code>README</code> in its top-level directory for details.
<hr>
-<h2>
-<a name="s-standards">6.2 Standard services and directory management</a>
-</h2>
+<a name="s-standards"></a>
+<h2>6.2 Standard services and directory management</h2>
<p>
-In later versions of this specification standard service names and
-interfaces for common services such as mail delivery and WWW CGI
-scripts may be specified.
-</p>
+In later versions of this specification standard service names and interfaces
+for common services such as mail delivery and WWW CGI scripts may be specified.
<p>
<code>userv</code>-using applications and system services which hide
-<code>userv</code> behind wrapper scripts may need to store information in
-the user's filespace to preserve the correct placement of the security
-perimiters. Such applications should usually do so in a directory
-(created by them) <samp>~/.userv/<var>service</var></samp>, where <var>service</var>
-is the service name or application in question.
-</p>
+<code>userv</code> behind wrapper scripts may need to store information in the
+user's filespace to preserve the correct placement of the security perimiters.
+Such applications should usually do so in a directory (created by them)
+<samp>~/.userv/<var>service</var></samp>, where <var>service</var> is the
+service name or application in question.
<p>
-If desired, a dot-directory inside <samp>~/.userv</samp> may be used to
-avoid the user becoming confused by finding parts of a semi-privileged
-application's internal state in their filespace, and/or discourage
-them from fiddling with and thus corrupting it.
-</p>
+If desired, a dot-directory inside <samp>~/.userv</samp> may be used to avoid
+the user becoming confused by finding parts of a semi-privileged application's
+internal state in their filespace, and/or discourage them from fiddling with
+and thus corrupting it.
<p>
However, <code>userv</code> applications should of course not rely for their
-global integrity and security on the integrity of the data on the
-user's side of the security boundary.
-</p>
+global integrity and security on the integrity of the data on the user's side
+of the security boundary.
<hr>
-<h2>
-<a name="s-reducepriv">6.3 Reducing the number of absolutely privileged subsystems</a>
-</h2>
+<a name="s-reducepriv"></a>
+<h2>6.3 Reducing the number of absolutely privileged subsystems</h2>
<p>
-Currently most Unix systems have many components which need to run as
-root, even though most of their activity does not strictly require
-it. This gives rise to a large and complex body of code which must be
-trusted with the security of the system.
-</p>
+Currently most Unix systems have many components which need to run as root,
+even though most of their activity does not strictly require it. This gives
+rise to a large and complex body of code which must be trusted with the
+security of the system.
<p>
If they were to use <code>userv</code>, many of these subsystems would no
longer need any unusual privilege.
-</p>
<p>
-<code>cron</code> and <code>at</code>, <code>lpr</code> and the system's mail transfer
-agent (<code>sendmail</code>, <code>smail</code>, <code>exim</code> or the like) all
-fall into this category, though <code>userv</code>-based versions of these
-programs are not currently available.
-</p>
+<code>cron</code> and <code>at</code>, <code>lpr</code> and the system's mail
+transfer agent (<code>sendmail</code>, <code>smail</code>, <code>exim</code> or
+the like) all fall into this category, though <code>userv</code>-based versions
+of these programs are not currently available.
<hr>
-<h2>
-<a name="s-noexcess">6.4 Do not give away excessive privilege to <code>userv</code>-using facilities</a>
-</h2>
+<a name="s-noexcess"></a>
+<h2>6.4 Do not give away excessive privilege to <code>userv</code>-using facilities</h2>
<p>
-There is a danger that people reimplementing the facilities I mention
-above using <code>userv</code> will discard much of the security benefit by
-using a naive implementation technique. This will become clearer with
-an example:
-</p>
+There is a danger that people reimplementing the facilities I mention above
+using <code>userv</code> will discard much of the security benefit by using a
+naive implementation technique. This will become clearer with an example:
<p>
-Consider the <code>lpr</code> 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>
+Consider the <code>lpr</code> 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 <code>userv</code>
-might involve giving the printer daemon (the <code>lp</code> user) the
-ability to read the file by allowing them to run <code>cat</code> (or a
-special-purpose file-reading program) as any user. The <code>lpr</code>
-program would use a <code>userv</code> 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>
+might involve giving the printer daemon (the <code>lp</code> user) the ability
+to read the file by allowing them to run <code>cat</code> (or a special-purpose
+file-reading program) as any user. The <code>lpr</code> program would use a
+<code>userv</code> 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 <code>lp</code> user will give the user the
-ability to read any file on the system.
-</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 <code>lp</code> 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 <code>lpr</code> 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>
+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 <code>lpr</code> 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>
+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 <code>userv</code>-based versions of
facilities which currently run as root.
-</p>
<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
-possibly creating a separate subdirectory of it as a dotfile to
-contain subsystem state) has fewer implications for the rest of the
-system and makes it entirely clear where the security boundaries lie.
-</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 possibly creating a
+separate subdirectory of it as a dotfile to contain subsystem state) has fewer
+implications for the rest of the system and makes it entirely clear where the
+security boundaries lie.
<hr>
-<h2>
-<a name="s-notreally">6.5 <code>userv</code> can often replace <code>sudo</code>, but not <code>really</code></a>
-</h2>
+<a name="s-notreally"></a>
+<h2>6.5 <code>userv</code> can often replace <code>sudo</code>, but not <code>really</code></h2>
<p>
-<code>userv</code> is not intended as a general-purpose system
-administration tool with which system administrators can execute
-arbitrary programs like text editors as root (or other system users)
-when they need to. It is unsuitable for this purpose precisely
-because it enforces a strong separation between the calling and the
-called program, which is undesirable in this context.
-</p>
+<code>userv</code> is not intended as a general-purpose system administration
+tool with which system administrators can execute arbitrary programs like text
+editors as root (or other system users) when they need to. It is unsuitable
+for this purpose precisely because it enforces a strong separation between the
+calling and the called program, which is undesirable in this context.
<p>
-However, its use when restricted to running particular programs in
-particular ways is very similar to many common uses of
-<code>sudo</code><a href="footnotes.html#2" name="fr2">[2]</a>. <code>userv</code> is
-generally much better than restricted <code>sudo</code>, because it protects
-the called program much more strongly from bad environmental
-conditions set up by the caller. Most programs that one might want to
-run via restricted <code>sudo</code>, have not been designed to run in a
-partially hostile environment. <code>userv</code> allows these programs to
-be run in a safer environment and should be used instead.
-</p>
+However, its use when restricted to running particular programs in particular
+ways is very similar to many common uses of <code>sudo</code>[<a
+href="footnotes.html#f2" name="fr2">2</a>]. <code>userv</code> is generally
+much better than restricted <code>sudo</code>, because it protects the called
+program much more strongly from bad environmental conditions set up by the
+caller. Most programs that one might want to run via restricted
+<code>sudo</code>, have not been designed to run in a partially hostile
+environment. <code>userv</code> allows these programs to be run in a safer
+environment and should be used instead.
<hr>
-<h2>
-<a name="s-stdinerr">6.6 Error handling and input streams (eg stdin)</a>
-</h2>
+<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>
+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>
+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.
-</p>
+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.
<hr>
-<h2>
-<a name="s-nogeneral">6.7 Don't give access to general-purpose utilities</a>
-</h2>
+<a name="s-nogeneral"></a>
+<h2>6.7 Don't give access to general-purpose utilities</h2>
<p>
-Do not specify general purpose programs like <code>mv</code> or <code>cat</code>
-in <code>execute-</code> directives without careful thought about their
-arguments, and certainly not if <code>no-suppress-args</code> is specified.
-If you do so it will give the caller much more privilige than you
+Do not specify general purpose programs like <code>mv</code> or
+<code>cat</code> in <code>execute-</code> directives without careful thought
+about their arguments, and certainly not if <code>no-suppress-args</code> is
+specified. If you do so it will give the caller much more privilige than you
probably intend.
-</p>
<p>
-It is a shame that I have to say this here, but inexperienced
-administrators have made similar mistakes with programs like
-<code>sudo</code>.
-</p>
+It is a shame that I have to say this here, but inexperienced administrators
+have made similar mistakes with programs like <code>sudo</code>.
<hr>
-[<a href="ch-ipass.html">back</a>]
- [<a href="index.html#abstract">Abstract</a>]
- [<a href="index.html#copyright">Copyright Notice</a>]
- [<a href="index.html#contents">Contents</a>]
+[ <a href="ch-ipass.html">previous</a> ]
+[ <a href="index.html#contents">Contents</a> ]
+[ <a href="ch-intro.html">1</a> ]
+[ <a href="ch-client.html">2</a> ]
+[ <a href="ch-envir.html">3</a> ]
+[ <a href="ch-config.html">4</a> ]
+[ <a href="ch-ipass.html">5</a> ]
+[ 6 ]
+[ <a href="index.html">next</a> ]
<hr>
-User service daemon and client specification<br>
+<p>
+User service daemon and client specification
<address>
-1.0.1<br>
-Ian Jackson <a href="mailto:ian@davenant.greenend.org.uk">ian@davenant.greenend.org.uk</a>
+1.0.3<br>
+Ian Jackson <code><a href="mailto:ian@davenant.greenend.org.uk">ian@davenant.greenend.org.uk</a></code>
</address>
+<hr>
+
</body>
</html>
~ian / userv.git / blobdiff