Discussion:
Bug#868316: cups-bsd: lpr does not print with "DefaultPolicy authenticated" in cupsd.conf
Add Reply
Christoph Pleger
2017-07-14 13:10:03 UTC
Reply
Permalink
Raw Message
Package: cups-bsd
Version: 2.2.1-8

Dear maintainers,

I do not know if it is a problem with the lpr program from cups-bsd or
with the cups daemon itself, but with "DefaultPolicy authenticated" in
cupsd.conf, lpr does not print, but the job remains in the print queue
for a while and then is removed.

Regards
Christoph
Brian Potkin
2017-07-14 16:00:02 UTC
Reply
Permalink
Raw Message
Thank you for your report, Christoph.
I do not know if it is a problem with the lpr program from cups-bsd or with
the cups daemon itself, but with "DefaultPolicy authenticated" in
cupsd.conf, lpr does not print, but the job remains in the print queue for a
while and then is removed.
You could try using lp to print but I cannot see that producing any
different an outcome.

We'll need an error_log; the Printing section of the wiki will guide
you in getting one. Compress it with gzip and send it to #868316.
Also attach your cupsd.conf and give the printer make and model.

Regards,

Brian.
Christoph Pleger
2017-07-17 08:20:01 UTC
Reply
Permalink
Raw Message
Hello,
Post by Brian Potkin
We'll need an error_log; the Printing section of the wiki will guide
you in getting one. Compress it with gzip and send it to #868316.
The log is attached. I stopped the cups daemon, removed the old
error_log, started the cups daemon, tried to print, and after the print
job had been removed from the queue, stopped the daemon. So, the log
contains only these steps.
Post by Brian Potkin
Also attach your cupsd.conf and give the printer make and model.
It is the original cupsd.conf copied from
/usr/share/cups/cupsd.conf.default at package installation, only with an
additional

DefaultPolicy authenticated

entry.

There are several printers, all of them remote printers imported by
cups-browsed - which is also currently broken related to authenticated
policy, see #868283, so that I installed an older version. Of course, I
verified that printing works with this older version of cups-browsed and
"DefaultPolicy default".

Regards
Christoph
Brian Potkin
2017-07-18 16:50:02 UTC
Reply
Permalink
Raw Message
Post by Christoph Pleger
Hello,
Post by Brian Potkin
We'll need an error_log; the Printing section of the wiki will guide
you in getting one. Compress it with gzip and send it to #868316.
The log is attached. I stopped the cups daemon, removed the old error_log,
started the cups daemon, tried to print, and after the print job had been
removed from the queue, stopped the daemon. So, the log contains only these
steps.
D [17/Jul/2017:09:55:22 +0200] [Client 63] 2.0 Send-Document 3
D [17/Jul/2017:09:55:22 +0200] Send-Document ipp://localhost:631/printers/nd50
D [17/Jul/2017:09:55:22 +0200] cupsdIsAuthorized: username=""
D [17/Jul/2017:09:55:22 +0200] [Client 63] Returning HTTP Nicht berechtigt for Send-Document (ipp://localhost:631/printers/nd50) from localhost

The username has an empty value, so sending the document is not
authorised. I have no idea why username is "".
Post by Christoph Pleger
Post by Brian Potkin
Also attach your cupsd.conf and give the printer make and model.
It is the original cupsd.conf copied from /usr/share/cups/cupsd.conf.default
at package installation, only with an additional
DefaultPolicy authenticated
entry.
There are several printers, all of them remote printers imported by
cups-browsed - which is also currently broken related to authenticated
policy, see #868283, so that I installed an older version. Of course, I
verified that printing works with this older version of cups-browsed and
"DefaultPolicy default".
I installed 1.10.0-1 and got printing with "DefaultPolicy default" but
none with "DefaultPolicy authenticated" - as happened to you. Then I
reverted to 1.11.6-3 and got no printing for either directive.

I wonder if this bug and #868283 have the same origin.

Regards,

Brian.
Christoph Pleger
2017-08-25 14:40:02 UTC
Reply
Permalink
Raw Message
Hello,

the bug at least somehow has to do with these lines in cups/request.c:

if (strcmp(cg->http->hostname, cg->server) ||
cg->ipp_port != httpAddrPort(cg->http->hostaddr) ||
(cg->http->encryption != cg->encryption &&
cg->http->encryption == HTTP_ENCRYPTION_NEVER))

The ports compared in line 2 are different, so that the connection is
closed. Though a new connection is opened immediately after, the new
connection does not have the authentication information from the
previous connection, so that authentication fails.

As on our hosts we use the cups unix socket anyway, a quick solution is
to comment out the second line.

Regards
Christoph
Christoph Pleger
2017-08-28 11:10:02 UTC
Reply
Permalink
Raw Message
Hello,

To be more exact, cg->ipp_port is 631, but
httpAddrPort(cg->http->hostaddr) is 0.

Regards
Christoph
Christoph Pleger
2017-08-28 13:00:02 UTC
Reply
Permalink
Raw Message
Hello,

I believe that I found a complete solution:

What introduced the bug, is that httpAddrPort() from http-addr.c now
returns 0 in the case when connection type is AF_UNIX. That differs from
the cups version in jessie, where httpAddrPort returned 631 in that
case. As in my opinion, it makes sense to return 0 as port number in an
AF_UNIX connection, I did not change http-addr.c, but request.c so that
the port comparison is only relevant if the connection type is not
AF_UNIX.

Patch is attached.

Regards
Christoph
Didier 'OdyX' Raboud
2017-08-28 14:00:01 UTC
Reply
Permalink
Raw Message
Control: tags -1 +upstream
Post by Christoph Pleger
What introduced the bug, is that httpAddrPort() from http-addr.c now
returns 0 in the case when connection type is AF_UNIX. That differs from
the cups version in jessie, where httpAddrPort returned 631 in that
case.
Right. This was changed for CUPS 2.2~ b1.
Post by Christoph Pleger
As in my opinion, it makes sense to return 0 as port number in an
AF_UNIX connection, I did not change http-addr.c, but request.c so that
the port comparison is only relevant if the connection type is not
AF_UNIX.
Thank you for the patch. It seems, from what I understand, that this change
could have unintended consequences outside of the scope of fixing your very
bug; it also really looks like something I'd like upstream to vouch for.

Would you be interested to push a pull-request to upstream? It doesn't make a
lot of sense for me to play proxy

https://github.com/apple/cups

I'll happily backport whatever patch upstream has accepted!

Cheers,
OdyX
Christoph Pleger
2017-08-28 14:50:02 UTC
Reply
Permalink
Raw Message
Hello,
Post by Didier 'OdyX' Raboud
Would you be interested to push a pull-request to upstream? It doesn't make a
lot of sense for me to play proxy…
https://github.com/apple/cups
Done, though I do not understand what you see as a possible problem
there. I guess that comparison of port numbers in an AF_UNIX connection
never makes sense ...

Regards
Christoph
Didier 'OdyX' Raboud
2017-08-28 16:20:02 UTC
Reply
Permalink
Raw Message
Post by Christoph Pleger
Done, though I do not understand what you see as a possible problem
there. I guess that comparison of port numbers in an AF_UNIX connection
never makes sense ...
Thank you; I've marked this bug as 'forwarded', accordingly.

You might want to edit your pull-request to either target the branch-2.1 from
upstream, or rebase yours on top of upstream's master; as-it-is it's quite
confusing :-/

https://github.com/apple/cups/pull/5098

Cheers,
OdyX
Christoph Pleger
2017-08-29 07:10:02 UTC
Reply
Permalink
Raw Message
Hello,
Post by Didier 'OdyX' Raboud
You might want to edit your pull-request to either target the
branch-2.1 from
upstream, or rebase yours on top of upstream's master; as-it-is it's quite
confusing :-/
The request has already been acted on and the issue is closed. They did
not exactly apply my patch, but their solution does quite the same.

Regards
Christoph
Didier 'OdyX' Raboud
2017-08-29 07:10:02 UTC
Reply
Permalink
Raw Message
Post by Christoph Pleger
The request has already been acted on and the issue is closed. They did
not exactly apply my patch, but their solution does quite the same.
Yep. I've seen; I am uploading the upstream snapshot to experimental and will
backport that patch to unstable immediately after. Thank you very much for
your time and energy!

Cheers,
OdyX

Loading...