Using userv many of these subsystems 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.
Consider the lpr 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.
A simple-minded approach to converting this scheme to use userv
might involve giving the printer daemon (the lp user) the ability
to read the file by allowing them to run cat (or a
special-purpose file-reading program) as any user. The lpr
program would use a userv service to store the filename in the
printer daemon's queues, and the daemon would read the file later when
it felt like it.
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 lp user will give the user the
ability to read any file on the system.
Instead, it is necessary to keep a record of which files the daemon has been asked to print outside 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 lpr 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.
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.
Similar considerations apply to many userv-based versions of 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.
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.
execute- directives without careful thought about their
arguments, and certainly not if no-suppress-args is specified.
If you do so it will give the caller much more privilige than you
probably intend.It is a shame that I have to say this here, but inexperienced administrators have made similar mistakes with programs like sudo.