Russell Coker wrote:
On Tuesday 15 November 2005 03:03, Michael Sweet <mike@xxxxxxxxxx> wrote:
b) the functionality for modifying those files could be placed in a
separate helper program executed by cupsd, so that we could run that
helper in a separate domain from cupsd and not give the daemon direct
access to rewriting the files,
That would seriously impact performance and make the code a lot more
complicated. Given that cupsd owns and writes these files, adding
helper apps would have little practical benefit for CUPS 1.2.
Is writing config files really a performance bottleneck? I imagine that for
the majority of the run time of the daemon there are no changes being made to
the configuration.
Since printers.conf, classes.conf, and subscriptions.conf are updated
whenever the configuration or state of a printer, class, or subscription
is updated, it can account for a good amount of time on a busy server
with lots of printers/classes. We've looked at only writing the files
on a server restart/shutdown, however you run into the possibility that
a server crash will lose all of the configuration changes you've made.
Also, when we add that plug-in interface to support alternate storage
mechanisms we'll also be providing information on the user that made
the change (and the nature of the change) to provide important
auditing information, so we'll need to save every change to preserve
that information anyways...
Also, note that SELinux provides an API for application policy enforcers
to support finer-grained controls over application abstractions, and
this API is already being used by dbusd and nscd (and a patch exists for
X, but isn't yet upstream). Hence, it might make sense to look into
using that API from cupsd as well (when running on a SELinux-enabled
system, of course, which you can detect at runtime). That allows you to
then define SELinux policy over those operations in addition to your
existing checks.
I'm not sure that really buys us anything - we already have a system
in place that can be used on all systems and provides remote access
policies above an beyond the UNIX accounts on the system.
You may (and often will) have multiple programs running with the same Unix UID
but different SE Linux security context. To handle this situation correctly
it is often necessary to have SE Linux support in applications. For example
if we have a printer in a public area and a printer in a secure area we want
to make sure that documents printed at a high MLS sensitivity level can only
go to the printer in the secure area. Implementing this requires that the
CUPS server know about SE Linux access controls. I believe that code is
already being written to implement such functionality.
Our government customers do not support both secure and non-secure
resources from a single server - it violates the policies they have in
place. Assuming that, at some point, they trust selinux enough to
change those policies and run classified and unclassified processing
on the same system image, you will need to make extensive changes at
both the client and server levels in order to securely pass and
authenticate the document classification data.
In short, CUPS is a network service and supporting such a
configuration would require a lot more work than adding some simple
API hooks which, AFAIK, lack the network scope that is required.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com
|
