Bug#689991: CUPS: error_log flooded due to AllowUser restriction
On Tue 25 Feb 2014 at 15:28:37 +0100, Didier Raboud wrote:
> Le vendredi, 26 avril 2013, 13.08:22 Alberto Gonzalez Iniesta a écrit :
> > I'm also experiencing this problem when my print clients were upgraded
> > from Ubuntu 10.04 to 12.04 [1]. The CUPS server [2] runs Debian
> > Squeeze.
>
> Alberto, Sergio: is this problem still present with a Wheezy CUPS
> server?
I think the bug is only triggered when a Wheezy CUPS is acting as a
client and using the ipp backend to send a job to a Squeeze, Wheezy or
Sid CUPS server. For example:
Sid has cups 1.7.1-6. A print queue allowing only the user debian to
print was set up. The queue was advertised using the CUPS protocol and
from a Wheezy system (newly installed) a job was sent to it. The server
says:
D [27/Feb/2014:15:10:10 +0000] [Client 19] 2.0 Create-Job 1
D [27/Feb/2014:15:10:10 +0000] Create-Job ipp://192.168.7.220:631/printers/TEST-AllowUser
W [27/Feb/2014:15:10:10 +0000] Unexpected 'document-format' operation attribute in a Create-Job request.
I [27/Feb/2014:15:10:10 +0000] Unexpected 'job-id' Job Descriptionattribute in a job creation request.
I [27/Feb/2014:15:10:10 +0000] Unexpected 'job-media-sheets-completed' Job Description attribute in a job creation request.
I [27/Feb/2014:15:10:10 +0000] Unexpected 'job-state' Job Description attribute in a job creation request.
I [27/Feb/2014:15:10:10 +0000] Unexpected 'time-at-creation' Job Description attribute in a job creation request.
I [27/Feb/2014:15:10:10 +0000] Unexpected 'time-at-processing' Job Description attribute in a job creation request.
I [27/Feb/2014:15:10:10 +0000] Denying user "brian" access to printer "TEST-AllowUser"...
D [27/Feb/2014:15:10:10 +0000] Create-Job client-error-not-authorized: Not allowed to print.
E [27/Feb/2014:15:10:10 +0000] [Client 19] Returning IPP client-error-not-authorized for Create-Job (ipp://192.168.7.220:631/printers/TEST-AllowUser) from 192.168.7.211
D [27/Feb/2014:15:10:10 +0000] [Client 19] Content-Length: 115
D [27/Feb/2014:15:10:10 +0000] cupsd is not idle any more, canceling shutdown.
D [27/Feb/2014:15:10:10 +0000] [Client 19] cupsdWriteClient error=0, used=0, state=HTTP_STATE_POST_SEND, data_encoding=HTTP_ENCODING_LENGTH, data_remaining=115, response=0xb8bc6688(IPP_IDLE), pipe_pid=0, file=-1
D [27/Feb/2014:15:10:10 +0000] [Client 19] Writing IPP response, ipp_state=DATA, old wused=0, new wused=0
D [27/Feb/2014:15:10:10 +0000] [Client 19] bytes=0, http_state=0, data_remaining=0
D [27/Feb/2014:15:10:10 +0000] [Client 19] Waiting for request.
D [27/Feb/2014:15:10:10 +0000] cupsdSetBusyState: newbusy="Not busy", busy="Active clients"
D [27/Feb/2014:15:10:10 +0000] cupsd is not idle any more, canceling shutdown.
D [27/Feb/2014:15:10:10 +0000] [Client 19] POST /printers/TEST-AllowUser HTTP/1.1
D [27/Feb/2014:15:10:10 +0000] cupsdSetBusyState: newbusy="Active clients", busy="Not busy"
D [27/Feb/2014:15:10:10 +0000] [Client 19] No authentication data provided.
D [27/Feb/2014:15:10:10 +0000] cupsd is not idle any more, canceling shutdown.
This is repeated many times. The server is an oldish machine; its CPU is
at 95% usage.
The client has:
D [27/Feb/2014:15:08:02 +0000] [Job 1] Create-Job IPP/2.0
D [27/Feb/2014:15:08:02 +0000] [Job 1] printer-uri="ipp://192.168.7.220:631/printers/TEST-AllowUser"
D [27/Feb/2014:15:08:02 +0000] [Job 1] requesting-user-name="brian"
D [27/Feb/2014:15:08:02 +0000] [Job 1] job-name=".profile"
D [27/Feb/2014:15:08:02 +0000] [Job 1] document-format="text/plain"
D [27/Feb/2014:15:08:02 +0000] [Job 1] Create-Job: client-error-not-authorized (Not allowed to print.)
Again repeated many times.
A Jessie client (cups 1.7.1-5) behaves normally with a Sid server unless
its ipp backend is replaced by the one from Wheezy.
It was remiss of me not to have pushed the initial report of the bug
upstream, but the str database was offline and I also had got it into my
head that upstream was not considering any further changes to 1.5.3. If
it is thought appropriate I could make amends for this lack of
judgement. :)
Regards,
Brian.
Reply to: