[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