[cups.bugs] Re: [MOD] STR #1487: rpmbuild fails on x86_64

Michael Sweet mike at easysw.com
Thu Mar 16 10:49:44 PST 2006


Klaus Singvogel wrote:
> ...
> Maybe it's the "triggers other dependencies", which contains a lot of
> room of speculation.

As I recall (and mind you I haven't messed with SuSE 9.2 on x86_64
since I had the original problems, and have since moved on to RHEL4)
the issue was that cups-32bit-libs (or something like that) depended
on cups-libs, but installing ESP Print Pro (32-bit binaries for
the moment) would replace cups-libs but not cups-32bit-libs, and
all of the CUPS-dependent packages needed the 64-bit libraries.

When we tried to build the mixed 64/32-bit ESP Print Pro packages
for SuSE, we found that there was no way to generate 32-bit
binaries with the included GCC, and since that won't work for our
build farm, SuSE on x86_64 was dropped.

>> I've had the displeasure of providing support for your customers
>> who have no end of trouble with your CUPS packages...
> 
> I wasn't aware of this. Sorry.
> 
> May I ask you, what the trouble was in particular?

The typical problem is the use of RunAsUser (which is gone in CUPS
1.2, BTW) which prevents many LPD printers from working and the
lack of lppasswd setup on installation, i.e. the root password is
not mirrored in that file, for example, and the user isn't asked
for a password for it, either.

Both problems are easily solved by not using "RunAsUser", and in
CUPS 1.2 you won't have a choice if you want to bind to port 631.

>> Given that I am *not* disconnected from customer support like you
>> are, I see a lot more problems than you do, apparently.
> 
> Yes, it sometimes is an advantage, if you don't have to do customer
> support, especially, if you more packages and not just the printing
> system at all.
> 
> But on the other side, I'm sitting in middle of two chairs with
> different opinions: the security team, which wants a lot of
> restrictions regarding open daemons, and the customer who sometimes
> wants a lot of freedom of his system. Both opinions contradict...
> 
> As a side note: as I already read in one of your announcements that
> cups-1.2 will no longer run as user, it might be possible I'm unable
> to avoid that the start of the daemon is disabled in a standard
> system. The user might need to push a button to enable it in future.
> This will happen then through demands of our security team.

RunAsUser exposed as many security issues as it prevented while 
significantly reducing the functionality of the server.

We looked at using seteuid() and friends to run the scheduler
as a non-privileged user when we didn't need it, but in the end
that is just smoke-and-mirrors - if you *did* manage to exploit
a bug to run code, you could do the seteuid call to become root
just as easily, and then do what you wanted to do in the first
place.

I would highly recommend that your "security" team look at
SELinux or any of the other Linux security modules.  They are
very effective at limiting what cupsd can and can't do, and
the Red Hat folks have done a good job with the CUPS policies
so far (just some minor issues for CUPS 1.2 to resolve...)

I'm hoping the new policy module stuff will allow us to ship
an SELinux policy module with CUPS so that all distros can take
advantage of it.

Aside from RunAsUser, we have also updated the backend interface.
Backends now run as the unprivileged user by default unless they
are mode 700 (executable only by root).  This reduces the number
of root-running programs to 3 (cupsd, ipp, and lpd).

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com




More information about the cups-devel mailing list