+The companion package, userv-utils, contains a selection of
+example services, some of which are useful tools in their own right.
+See the README in its top-level directory for details.
+
In later versions of this specification standard service names and interfaces for common services such as mail delivery and WWW CGI -scripts will be specified. +scripts may be specified.
@@ -41,24 +53,27 @@ scripts will be specified.
userv 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) ~/.userv/.servdata/service, where
-service is the service name or application in question.
+(created by them) ~/.userv/service, where service
+is the service name or application in question.
+
+If desired, a dot-directory inside ~/.userv 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.
-The use of a dot-directory inside ~/.userv will hopefully 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. (Note that such
-applications should of course not rely for their global integrity on
-the integrity of the data on the user's side of the security
-boundary.)
+However, userv 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.
@@ -69,20 +84,21 @@ trusted with the security of the system.
-Using userv many of these subsystems no longer need any unusual
-privilege.
+If they were to use userv, many of these subsystems would no
+longer need any unusual privilege.
cron and at, lpr and the system's mail transfer
agent (sendmail, smail, exim or the like) all
-fall into this category.
+fall into this category, though userv-based versions of these
+programs are not currently available.
userv-using facilities
+6.4 Do not give away excessive privilege to userv-using facilities
@@ -154,39 +170,76 @@ facilities which currently run as root. 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. +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.
userv is not a replacement for really and sudo
+6.5 userv can often replace sudo, but not really
userv is not intended as a general-purpose system
administration tool with which system administrators can execute
-privileged programs 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.
+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.
+
+However, its use when restricted to running particular programs in
+particular ways is very similar to many common uses of
+sudo[2]. userv is
+generally much better than restricted sudo, 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 sudo, have not been designed to run in a
+partially hostile environment. userv allows these programs to
+be run in a safer environment and should be used instead.
+
+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 userv and not to the same object as was presented by
+the caller.
+
+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.
-Its facilities for restricting activities to running certain programs
-may at first glance seem to provide similar functionality to
-sudo[2]. However, the
-separation mentioned above is a problem here too, particular for
-interaction - it can be hard for a userv service program to
-interact with its real caller or the user in question.
+For example, consider a userv 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.