cups-lpd: Unable to reserve port: Permission denied

[Garry Williams]

I recently noted that print jobs from my FC6 machine sent to my remote
lpd print server take over five minutes to actually be spooled to
print server.  When I strace the cups process that connects to the
remote lpd, I see repeated attempts to bind() to port numbers below
1024.  Each attempt fails with EACCES even though the process is
running as root.  After each failure, the lpd client waits for one
second, then decrements the port number and tries again.  This
sequence repeats until port number 631 is tried.  That succeeds and
the client calls connect() and the print job is sent to the remote
printer.

My theory (based on suggestions from the fedora-user mailing list) is
that there is a new selinux policy that restricts the cupsd process
and its children to only be able to bind to port 631.  If this is
true, I believe it is incorrect.

I think that there are some older lpd servers that insist on
validating clients based on their source port numbers, refusing to
allow connections from clients using ports over 1024.  This behavior
will probably be judged silly (at best) these days, but there seems to
be a need to support it even today.  Consequently, the default
behavior of cups-lpd seems to insist on a low port number before
calling connect().

I got around the problem by specifying a printer URI that suppresses
that behavior.  (That wasn't obvious to me -- I got there from a
suggestion from David Hull, replying to my question on the fedora-user
list.)  But the cups developers think this is OK behavior for their
client when it needs to talk to some servers.

I think the new policy is wrong.  Regardless, why don't I see avc log
messages on this?

-- 
Garry T. Williams --- [phone]

[Matt Anderson]

Garry T. Williams wrote:
>  I recently noted that print jobs from my FC6 machine sent to my
> remote
>  lpd print server take over five minutes to actually be spooled to
>  print server.  When I strace the cups process that connects to the
>  remote lpd, I see repeated attempts to bind() to port numbers below
>  1024.  Each attempt fails with EACCES even though the process is
>  running as root.  After each failure, the lpd client waits for one
>  second, then decrements the port number and tries again.  This
>  sequence repeats until port number 631 is tried.  That succeeds and
>  the client calls connect() and the print job is sent to the remote
>  printer.
>  
>  My theory (based on suggestions from the fedora-user mailing list) is
>  that there is a new selinux policy that restricts the cupsd process
>  and its children to only be able to bind to port 631.  If this is
>  true, I believe it is incorrect.
>  
>  I think that there are some older lpd servers that insist on
>  validating clients based on their source port numbers, refusing to
>  allow connections from clients using ports over 1024.  This behavior
>  will probably be judged silly (at best) these days, but there seems to
>  be a need to support it even today.  Consequently, the default
>  behavior of cups-lpd seems to insist on a low port number before
>  calling connect().
>  
>  I got around the problem by specifying a printer URI that suppresses
>  that behavior.  (That wasn't obvious to me -- I got there from a
>  suggestion from David Hull, replying to my question on the fedora-user
>  list.)  But the cups developers think this is OK behavior for their
>  client when it needs to talk to some servers.
>  
>  I think the new policy is wrong.  Regardless, why don't I see avc log
>  messages on this? 
It seems to me that the AVCs are lost because they are don't audited.
If you put in place the enableaudit.pp policy file then you'd probably
see them.

cupsd should only be able to bind to port 631, but your client's should
be able to use high ports to connect to the remote server.  From what
you've said it sounds like the printer you are lpr'ing to is a locally
defined print spool that cupsd is supposed to then queue up and send to
remote printers.  If that is the case then why not configure the queue
so that lpr sends jobs directly to the remote queue?  Or am I missing
something.

-matt

[Garry Williams]

On Thursday 05 April 2007 19:01:19 Matt Anderson wrote:
>  Garry T. Williams wrote:
>  > I think the new policy is wrong.  Regardless, why don't I see avc log
>  > messages on this?
>  
>  It seems to me that the AVCs are lost because they are don't audited.
>  If you put in place the enableaudit.pp policy file then you'd probably
>  see them. 
Thanks for the pointer.  This will save debug time.  :-)

>  cupsd should only be able to bind to port 631, but your client's
> should
>  be able to use high ports to connect to the remote server.  From what
>  you've said it sounds like the printer you are lpr'ing to is a locally
>  defined print spool that cupsd is supposed to then queue up and send to
>  remote printers.  If that is the case then why not configure the queue
>  so that lpr sends jobs directly to the remote queue?  Or am I missing
>  something. 
I simply defined a remote lpd printer to cups and then printed to it
from an application like a2ps or firefox.  This causes my local cupsd
process to fork a client to connect to the remote lpd.  In general,
TCP clients don't need to bind to a specific port.  In general, TCP
clients don't even call bind().  But...

Because of historical conventions (as I understand it), some lpd
*servers* refuse to allow connections from clients coming from source
ports above 1024.  Yes, it's silly, but the cups folks claim that
there are such servers that cups needs to support.  Because of this,
the default behavior for cups-lpd running in *client* mode is to bind
to a low-numbered port before connecting to the server.  The new
selinux policy forbids this.  As a matter of fact, the cups-lpd
running as a client *can't* bind to the permitted port 631, if the
cups server has already done so.

(I don't run cupsd on anything but localhost on this machine, so the
bind eventually succeeded when cups-lpd finally counted down to 631
retrying bind() along the way.)

If you accept that it is legitimate for cups-lpd to insist on a
low-numbered port that is not 631, then the current policy is flawed.
The client mode will never call listen(), so it doesn't become a
server.  It just wants a low source port when it connects to another
server.

-- 
Garry T. Williams --- [phone]

[Daniel J Walsh]

Garry T. Williams wrote:
>  On Thursday 05 April 2007 19:01:19 Matt Anderson wrote:
>    
> > Garry T. Williams wrote:
> >     
> >> I think the new policy is wrong.  Regardless, why don't I see avc log
> >> messages on this?
> >>       
> > It seems to me that the AVCs are lost because they are don't audited.
> > If you put in place the enableaudit.pp policy file then you'd probably
> > see them.
> >     
>
>  Thanks for the pointer.  This will save debug time.  :-)
>
>    
> > cupsd should only be able to bind to port 631, but your client's should
> > be able to use high ports to connect to the remote server.  From what
> > you've said it sounds like the printer you are lpr'ing to is a locally
> > defined print spool that cupsd is supposed to then queue up and send to
> > remote printers.  If that is the case then why not configure the queue
> > so that lpr sends jobs directly to the remote queue?  Or am I missing
> > something.
> >     
>
>  I simply defined a remote lpd printer to cups and then printed to it
>  from an application like a2ps or firefox.  This causes my local cupsd
>  process to fork a client to connect to the remote lpd.  In general,
>  TCP clients don't need to bind to a specific port.  In general, TCP
>  clients don't even call bind().  But...
>
>  Because of historical conventions (as I understand it), some lpd
>  *servers* refuse to allow connections from clients coming from source
>  ports above 1024.  Yes, it's silly, but the cups folks claim that
>  there are such servers that cups needs to support.  Because of this,
>  the default behavior for cups-lpd running in *client* mode is to bind
>  to a low-numbered port before connecting to the server.  The new
>  selinux policy forbids this.  As a matter of fact, the cups-lpd
>  running as a client *can't* bind to the permitted port 631, if the
>  cups server has already done so.
>
>  (I don't run cupsd on anything but localhost on this machine, so the
>  bind eventually succeeded when cups-lpd finally counted down to 631
>  retrying bind() along the way.)
>
>  If you accept that it is legitimate for cups-lpd to insist on a
>  low-numbered port that is not 631, then the current policy is flawed.
>  The client mode will never call listen(), so it doesn't become a
>  server.  It just wants a low source port when it connects to another
>  server.
>
>     
I have added the ability for cups to bind to any port 600-1023.

selinux-policy-2.5.11-5.fc7