dapper cupsys can not print to rfc compliant lpd server, i.e. can not run as root

I'm afraid I don't get what you mean. cupsd does not need any privileges to print to a port of an LPD server (since it acts as client in this case). OTOH, cupsd opens the ports it needs before dropping privileges (i. e. 631 by default).

So what exactly is the problem?

Martin Pitt wrote:

>I'm afraid I don't get what you mean. cupsd does not need any privileges
>to print to a port of an LPD server (since it acts as client in this
>case). OTOH, cupsd opens the ports it needs before dropping privileges
>(i. e. 631 by default).
>
>So what exactly is the problem?
>
>** Changed in: cupsys (Ubuntu)
> Status: Unconfirmed => Needs Info
>
>
>
I'll get back to you. I should point out that I had to use
RunAsUser no in breezy to get it to work. I explicitly
told cupsd to use reserved ports in the URI. Previously
it wouldn't print. Yes, I tried it without the ?reserved
option and that didn't work either.

walter

ps. There are some problems in this package when one
attempt remote administration (even after reactivation)
I'll report this separately.

Martin Pitt wrote:

>I'm afraid I don't get what you mean. cupsd does not need any privileges
>to print to a port of an LPD server (since it acts as client in this
>case). OTOH, cupsd opens the ports it needs before dropping privileges
>(i. e. 631 by default).
>
>So what exactly is the problem?
>
>** Changed in: cupsys (Ubuntu)
> Status: Unconfirmed => Needs Info
>
>
>
Ok. Tried cupsd on dapper release (as of today) and I added
a lpd printer with URI lpd://server/queue_name and I
tried a URI lpd://server/queue_name?reserve=yes
both times I get:

it responds with

    "/usr/lib/cups/backend/lpd failed"

unfortunately the log file (at debug2 level) says nothing helpful.
I have included a gzipped version of it as an attachment. Perhaps
you can spot something. Let me know if you need additional info.

walter

I sent an attachment via mail. Not sure it got through since
i didn't see it here so I've gone the web way and attached it.

You do not need/want cups to run as root for this. In this case, cups is a client which connects via high ports (over 1024) to lpd server.

I'll have to take a detailed look at this, but if you want to give a shot to these packages:

http://www.grad.hr/~ivoks/ubuntu/cups

please, report results.

Ante Karamatić wrote:

>You do not need/want cups to run as root for this. In this case, cups is
>a client which connects via high ports (over 1024) to lpd server.
>
>I'll have to take a detailed look at this, but if you want to give a
>shot to these packages:
>
>http://www.grad.hr/~ivoks/ubuntu/cups
>
>please, report results.
>
>
>
Perhaps it depends on what lpd server is used. We have
an old old version lpd locally hacked. In particular the lpr command
is setuid root so I suspect your claims about client connections
aren't allowed with our server. I'll have to take a look at the
lpr log files. Perhaps lprng allows connections from higher
ports? I know our doesn't. IN any event I've compiled a source
package from cups.org and run as root. I use this as an intermediary
server. Ultimately our environment will run cups directly to the
printers at which point the cups servers in ubuntu may actually
work.

I noticed that the userid cupsys is hacked directly into the source
files. Doesn't strike me as a good idea. Ideally it should be define
variable the could be specified via a define and set via configure
at build time or, dare I say it, via configuration file at run time.

In our source we have:
    if (f->sin_family != AF_INET || f->sin_port >= IPPORT_RESERVED)
           fatal("Malformed from address");

I'm no c-coding guru. I believe a child root process handles jobs arriving
in various queues once a job arrives.

<b>How</b> does <i>this</i> thingie work? No markup guide in sight...

_Like_ *this*? Or 'like' ''this''? '''Hmm...'''

--> "You do not need/want cups to run as root for this." <--
----------------

Yes you do, at least in the context of this bug report. The bug report explicitely names an "RFC compliant LPD server".

In case you are not familiar with RFC 1179 (which is the one that descibes LPD), please have a look yourself.

But since I do not trust you that you do actually look at it, I'll give you a summary (despite my suspicion that you'll just ignore it):

* Though RFC never made it into a "proposed standard", and always stayed on the "informational" level in the RFC standards track of IANA, LPD along the lines that 1179 summarized was widely implemented.

* Unfortunately RFC 1179 makes the (stupid) recommendation that LPD clients "source ports must be in the range 721 to 731, inclusive".

* This led to many strict LPD server implementations not accepting printjobs that do originate from other ports than 721 through 731.

* This led to problems even with MS Windows printing (which became very slow and unperformant, when due to long TCP/IP timeouts only 11 possible source ports were not enough to supply for "many 1-page jobs quickly". That was "fixed" in NT-4.0 Service Pack 3, which introduced "non LPD source port printing".

* SP3's measure in turn exerted more pressure on "compliant" LPD implementations to be patched for a more liberal handling of clients.

* nowadays many of the still existing LPD servers do also accept job transmissions originating from other ports (especially ones that are above 1024 and can be used by non-root users) -- but there are still others out there....

* CUPS itself uses a liberal implementation, using by default "above 1024" source ports for its lpd:// backend.

* If a CUPS admin finds that the target printer (or print server) insists on strict 721-731 source code compliance, he can force the printqueue's lpd:// backend into limiting itself to these source ports by adding the named "?reserve=yes" specification to the device URI

--> "In this case, cups is a client which connects via high ports (over 1024) to lpd server." <--
----------------

Hopefully you do see now that you was completely wrong with your statement.

----------------

Let me add a general advice/request/wish/suggestion for you to consider: Since Ubuntu packagers do heavily patch upstream sources to make them behave completely differently from what is officially documented, it would be not asked too much from you if you'd also actively participate in the CUPS forums. You could only learn from it, even very, very trivial things about printing, that you do not have much clue about currently. *If* you dare to patch (in effect, even _fork_ !!) CUPS, then you should at least be familiar with the design desicions taken, with the reasoning behind them, and the general use cases that lead to certain configuration defaults. But unfortunately, your participation over at CUPS.org in recent years was very thinly spread out.

Kurt thank you for clearing this up. As for Ubuntu patching source, you can very easily check it and you'll see Ubuntu has less than 100 lines of diff regarding to Debian package (if you exclude fixes from CUPS CVS). Most of those lines are in cupsd.conf, not the source.

I think buglist is not for discussing mine/yours/others contribution to CUPS/Ubuntu/whatever, so please let's leave this as a bug report.

So why is this bug still in status "needs info"?

It's between "Rejected" and "Confirmed". For fixing this bug we should run cups as root or introduce setuid program.

Ante Karamatić wrote:
> It's between "Rejected" and "Confirmed". For fixing this bug we should
> run cups as root or introduce setuid program.
>
> ** Changed in: cupsys (Ubuntu)
> Status: Needs Info => Confirmed
>
>
Hi, In a recent thread Michael Sweet outlined point by point
why not running as root breaks things. Of course, he is open
to patches.
> Michael, Does cups allow running as a non-root user? Obviously
> I know I could just start it up as a non-root user but that clearly
> implies it would have limited capabilities from the start.
>
> Most daemons that run as a non-root user usually start up
> as root and then exec a child with lesser priviledges *after*
> they checked things like permissions and the like.
Michael responds:

Actually, it is a crap shoot whether the daemon will do this
for you, however for CUPS we MUST run as root in order to do
many common things. As I covered in my presentation at the
Linux Printing Summit this year, running as an unprivileged
user is actually *less* secure with CUPS, as you lose the
privilege separation between scheduler and filters which have
a lot less auditing done on them...

> The debian boys have hardwired the userid cupsys into
> the code. It would be nice if there were a way to do this
> in a cleaner way using your original source. Perhaps a compile
> time define or perhaps the USER variable could be used to
> identify the userid that cupsd should run as? I know
> you've deprecated RunAsUser but....
Michael responds,

We aren't going to bring back RunAsUser. All of the Linux distros
already provide helper functions for their init scripts to run as
a different user, I suggest you look there if you really want to
cripple your CUPS install. You will also need to update the
/etc/services file on every system that wants to print with the
new port number for the IPP service...

FWIW, the following will not work if you don't run as root:

    1. Printing and browsing on port 631 (or any port < 1024)
    2. Automatic root authentication via certificates.
    3. Proxy authentication support (you'll need to hardcode
       usernames and passwords in your device URIs again).
    4. Local account authentication via PAM (although I've
       heard there is now a workaround for this by adding the
       user you run cupsd as to a PAM group)
    5. LPD printing support.
    6. Legacy client support via /etc/printcap and
       /etc/printers.conf. This kills printing from GNOME apps
       on Solaris 10, for example.
    7. (future) Kerberos support.

You are also leaving yourself open to filter-based attacks because
of the loss of privilege separation.
-------------------end of Michael and my exchange with him
--------------------

Me: Number 5 is relevant to this bug report.
-

On Mon, 26 Jun 2006 15:04:28 -0000
Walter Tautz <email address hidden> wrote:

> We aren't going to bring back RunAsUser. All of the Linux distros
> already provide helper functions for their init scripts to run as
> a different user, I suggest you look there if you really want to
> cripple your CUPS install. You will also need to update the
> /etc/services file on every system that wants to print with the
> new port number for the IPP service...

This is a known problem. RunAsUser would be great to bring back (this
is why Debian/Ubuntu patches CUPS). Mike knows that RunAsUser and
"helper functions for init scripts" (i.e. start-stop-daemon) are two
totally different things. stat-stop-daemon starts CUPS as non-root user
and CUPS is unable to bind on TCP/631. RunAsUser allowed to start CUPS
as root and bind on TCP/631, and then drop privileges to non-root user.
This is how most of the services work (i.e. postfix, vsftpd, bind,
apache...). I don't see any reason why it shouldn't be done with CUPS
too. If argument is needed - sendmail. Sendmail acts just like CUPS;
runs everything as root. Sendmail is now kicked out of OpenBSD and is
loosing it's user base every day. There is no perfect "hole-free"
software. First line of defense is to assume one day that service will
have a remotly exploitable hole. It's muche better if attacker gains
non-root privileges with which he can "only" mess up printing queues.

> 5. LPD printing support.
> Me: Number 5 is relevant to this bug report.

Yes, I think everybody knows that. I can say this won't be "fixed" for
Dapper, but maybe we work something out for Edgy.

Did you try setuid lpd backend (chmod
+s /usr/lib/cups/backend-available/lpd)?

--
Ante Karamatic | 0xD3BDA225 | 0x0A4A0161
<email address hidden> | <email address hidden> | ivoks.blogspot.com
"Tomorrow is my day off, so please stay off the powder!"

Ante Karamatić wrote:
> On Mon, 26 Jun 2006 15:04:28 -0000
> Walter Tautz <email address hidden> wrote:
>
>
>> We aren't going to bring back RunAsUser. All of the Linux distros
>> already provide helper functions for their init scripts to run as
>> a different user, I suggest you look there if you really want to
>> cripple your CUPS install. You will also need to update the
>> /etc/services file on every system that wants to print with the
>> new port number for the IPP service...
>>
>
> This is a known problem. RunAsUser would be great to bring back (this
> is why Debian/Ubuntu patches CUPS). Mike knows that RunAsUser and
> "helper functions for init scripts" (i.e. start-stop-daemon) are two
> totally different things. stat-stop-daemon starts CUPS as non-root user
> and CUPS is unable to bind on TCP/631. RunAsUser allowed to start CUPS
> as root and bind on TCP/631, and then drop privileges to non-root user.
> This is how most of the services work (i.e. postfix, vsftpd, bind,
> apache...). I don't see any reason why it shouldn't be done with CUPS
> too. If argument is needed - sendmail. Sendmail acts just like CUPS;
> runs everything as root. Sendmail is now kicked out of OpenBSD and is
> loosing it's user base every day. There is no perfect "hole-free"
> software. First line of defense is to assume one day that service will
> have a remotly exploitable hole. It's muche better if attacker gains
> non-root privileges with which he can "only" mess up printing queues.
>
>
>> 5. LPD printing support.
>> Me: Number 5 is relevant to this bug report.
>>
>
> Yes, I think everybody knows that. I can say this won't be "fixed" for
> Dapper, but maybe we work something out for Edgy.
>
> Did you try setuid lpd backend (chmod
> +s /usr/lib/cups/backend-available/lpd)?
>
>
Yeah. It didn't work. In anycase I've compiled a version of cups that runs
as root to get around my problem for the moment. Michael's perspective
is he doesn't want to break the print system as opposed to the host
that it's running on... a matter of perspective. I thought I'd give some
insights on his thinking....

Ante Karamatić wrote:
> On Mon, 26 Jun 2006 15:04:28 -0000
> Walter Tautz <email address hidden> wrote:
>
>
>> We aren't going to bring back RunAsUser. All of the Linux distros
>> already provide helper functions for their init scripts to run as
>> a different user, I suggest you look there if you really want to
>> cripple your CUPS install. You will also need to update the
>> /etc/services file on every system that wants to print with the
>> new port number for the IPP service...
>>
>
> This is a known problem. RunAsUser would be great to bring back (this
> is why Debian/Ubuntu patches CUPS). Mike knows that RunAsUser and
> "helper functions for init scripts" (i.e. start-stop-daemon) are two
> totally different things. stat-stop-daemon starts CUPS as non-root user
> and CUPS is unable to bind on TCP/631. RunAsUser allowed to start CUPS
> as root and bind on TCP/631, and then drop privileges to non-root user.
> This is how most of the services work (i.e. postfix, vsftpd, bind,
> apache...). I don't see any reason why it shouldn't be done with CUPS
> too. If argument is needed - sendmail. Sendmail acts just like CUPS;
> runs everything as root. Sendmail is now kicked out of OpenBSD and is
> loosing it's user base every day. There is no perfect "hole-free"
> software. First line of defense is to assume one day that service will
> have a remotly exploitable hole. It's muche better if attacker gains
> non-root privileges with which he can "only" mess up printing queues.
>
I'm hesitate to speak for Michael but have read him state
that he is not averse to having well-thought out patches
to allow for non-root running. How about helping him
out directly? I'd try to do it myself but I'm not
particularly experienced. It sounds like the maintainers
of cups in debian/ubuntu are :-)

>
>> 5. LPD printing support.
>> Me: Number 5 is relevant to this bug report.
>>
>
> Yes, I think everybody knows that. I can say this won't be "fixed" for
> Dapper, but maybe we work something out for Edgy.
>
> Did you try setuid lpd backend (chmod
> +s /usr/lib/cups/backend-available/lpd)?
>
>

Ante Karamatić wrote:

    'Mike knows that RunAsUser and "helper functions for init scripts" (i.e.
     start-stop-daemon) are two totally different things.'

I'm sure he knows that. What he meant to say was that a start-stop daemon solution should then also use a port above 1024 (instead of 631). Hence his further hint saying

    "You will also need to update the /etc/services file on every system that
      wants to print with the new port number for the IPP service"

Ante Karamatić also wrote:

    "This is how most of the services work (i.e. postfix, vsftpd, bind, apache...).
      I don't see any reason why it shouldn't be done with CUPS too."

It is obvious that you do not consider *all* the arguments that are in play when discussing this topic, and that you are merely repeating the same simple argument that *started* the discussion, long ago. If you are really interested in the complete picture, please read up the full discussions in the archives, and Mike's presentation on the Linux Desktop Printing Architect's Summit.

Oh, I forgot a very prominent and important service that does not comply with your principles for security, Ante: Samba.

I just checked with the box of a friend who runs Dapper: it has the original Dapper packages of Samba, and all smbd and nmbd processes do run as root....

I did another test and
chmod u+s /usr/lib/cups/daemon/cups-lpd does allow one
to print from a client running a rfc compliant lpr command I.e.,
a client that insists on connecting to a lpd server on
reserved port below 1024 (we have one). I setup cups-lpd
to be listening on my ubuntu box via inetd and tcp wrappers
and it works.

Back to the Original Subject of this Bug Report
============================

To address the problem of having an ubuntu client printing to an
RFC compliant lpd server I have succeeded in doing this
by doing chmod u+s /usr/lib/cups/backend-available/lpd, i.e.,
what did not work with earlier now works! Perhaps an update
did it or did you guys do something?

So I have some requests:
================

Could you folks add a question(s) to debconf for this package that
would allow people to turn setuid user bits on cups-lpd and the lpd
backend (available) . By default it should not
be on when the package installs but having the option to turn it on
would solve the problem. Furthermore you could include some notes in the debconf warning people appropriately. And a README.Ubuntu.gz
file.

Just to be clear printing from Ubuntu/Dapper to RFC compliant lpd
server it suffice to chmod u+s /usr/lib/cups/backend-available/lpd.

However having the ability to do chmod u+s /usr/lib/cups/daemon/cups-lpd
is also convenient as it solves a slightly similar problem or should I say
reverse issue. See previous note for details.

The easy and correct fix for edgy is indeed to install the backend suid root and drop privileges right after opening the port.

 cupsys (1.2.3-1ubuntu2) edgy; urgency=low
 .
   * debian/patches/56_dirsvc.dpatch: Update patch so that a patch/unpatch
     cycle restores the source properly instead of breaking dirsvc.c in two
     different places.
   * debian/rules: Install 'lpd' backend suid root (root:lp 4754), so that
     cupsd can print to RFC compliant lpd servers (which require the source
     port to be < 1024). Closes: LP#47773