[cups.bugs] [MOD] STR #2368: Current setuid() approach ofdeviced leads to unaccessible devices
Michael Sweet
mike at easysw.com
Wed May 2 06:00:44 PDT 2007
Martin Pitt wrote:
> Hi,
>
> Michael Sweet [2007-04-30 9:51 -0400]:
>> Sigh... seteuid() becomes the only UID after a fork.
>
> fork() does not change effective and real user IDs, and deviced does
> not even fork().
cups-deviced uses popen(), which uses fork+exec to run the backend.
>> The cups-deviced check honors the root/non-root permission check
>> done by the scheduler, and your patch disables that, running all
>> backends as root with the standard CUPS (and that exposes you to
>> more security risks...)
>
> Grr, can you pretty please look at the patch and my explanation first?
I did, but your patch just removes all of the permission checks.
*If* your patch changed the code to use fork+exec and did a
setuid call in the child process instead of calling popen(),
*then* I'd consider it.
As provided, your patch just increases the risk when running
as root. Since we MUST run as root to provide key functionality
expected of a printing system, we need to keep the checks in
place.
> The patch touches *deviced*, not *cupsd*, does not change backend
> invocation behaviour, it does not disable any permission checks, and
> seteuid() does not help you security-wise in any way with getuid()==0.
The UID check (!getuid()) just optimizes the code path - if we aren't
running as root, then we can't setuid() or seteuid() anyways.
If we *are* running as root, we need to honor the permission limits
used by the scheduler, namely world-executable backends get run as
an unprivileged user.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com
More information about the cups
mailing list