OpPolicy problem/bug: Sending job as non-authorized user nevertheless prints job as root user

Kurt Pfeifle k1pfeifle at gmx.net
Wed Jul 18 03:59:56 PDT 2007


Hi,

I'm trying to get an enterprise-wide CUPS installation up and running,
which is supposed to heavily rely on different Operation Policies for
different printers.

One issue with OpPolicy settings not fully working is already resolved
(STR #2319) by upgrading from CUPS 1.2.10 to 1.2.12.

Another issue remains. Summary:

   ====================================================================
   Sending a job as a member of a not-authorized group (correctly) logs
   'Print-Job: Unauthorized' in error_log, but then continues to print
   the job under the root user account.
   ====================================================================

Details:
--------

I found this weird behavior when trying to test our different Operation
Policies from the commandline. These policies in real life will only
affect Samba-submitted jobs and users/groups that are authenticated via
Samba+Winbind+PAM (i.e. there will be rarely jobs comming from the Unix
commandline).

However, to make my initial testing faster and scriptable, I've turned
to using the Unix commandline, running it as root, without requiring a
real MS Windows client undergoing a clicking orgy to submit a job.

So, I'm running (as root) the 'lp' command with the '-U' parameter to
specify a different username to use when connecting to the CUPS server.

The username used is a Windows domain user (authenticated via Samba+PAM+
Winbind) named 'BOS_ALL\kp_testprint' (BOS_ALL is the Windows Active Di-
rectory domain name).

The target printer uses a non-default OpPolicy named 'HR_printer' which
should allow access only to a few selected individual users and specific
groups containing Human Resources department employees.

Here are a few lines from a debug2 error_log (I deleted lines in between
which are less relevant IMHO -- full log is available should you want me
to submit an STR):

   d [18/Jul/2007:11:31:03 +0200] cupsdIsAuthorized: requesting-user-name="BOS_ALL\kp_drucktest"
   d [18/Jul/2007:11:31:03 +0200] cupsdIsAuthorized: Checking user membership...
   d [18/Jul/2007:11:31:03 +0200] cupsdCheckGroup(username="BOS_ALL\kp_drucktest", user=0x2c0078, groupname="sys")
   d [18/Jul/2007:11:31:03 +0200] cupsdCheckGroup(username="BOS_ALL\kp_drucktest", user=0x2c0078, groupname="root")
   d [18/Jul/2007:11:31:03 +0200] cupsdCheckGroup(username="BOS_ALL\kp_drucktest", user=0x2c0078, groupname="BOS_ALL\sch_human_resources")
   d [18/Jul/2007:11:31:03 +0200] cupsdCheckGroup(username="BOS_ALL\kp_drucktest", user=0x2c0078,
groupname="BOS_ALL\sch_human_resources_trainee")
   E [18/Jul/2007:11:31:03 +0200] Print-Job: Unauthorized
   D [18/Jul/2007:11:31:03 +0200] cupsdSendError: 7 code=401 (Unauthorized)

So far, so good.

What's not so good IMHO however, is what follows:

   d [18/Jul/2007:11:31:03 +0200] cupsdCloseClient: Removing fd 7 from InputSet and OutputSet...
   d [18/Jul/2007:11:31:03 +0200] cupsdAcceptClient(lis=0x80a1168) 2 Clients = 0
   D [18/Jul/2007:11:31:03 +0200] cupsdAcceptClient: 7 from localhost (Domain)
   d [18/Jul/2007:11:31:03 +0200] cupsdAcceptClient: 7 connected to server on localhost:631
   d [18/Jul/2007:11:31:03 +0200] cupsdAuthorize: con->uri="/printers/zzzpdf", con->best=0x80a1108(/)
   d [18/Jul/2007:11:31:03 +0200] cupsdAuthorize: Authorization="Local 4395C496022A34179F55978917A02177"
   D [18/Jul/2007:11:31:03 +0200] cupsdAuthorize: username="root"
   d [18/Jul/2007:11:31:03 +0200] cupsdIsAuthorized: con->uri="/printers/zzzpdf", con->best=0x80a1108(/)
   I [18/Jul/2007:11:31:03 +0200] Job 125614 queued on "zzzpdf" by "root".
   d [18/Jul/2007:11:31:03 +0200] start_job: id = 125614, file = 0/1
   D [18/Jul/2007:11:31:03 +0200] [Job 125614] argv[0]="zzzpdf"
   D [18/Jul/2007:11:31:03 +0200] [Job 125614] argv[1]="125614"
   D [18/Jul/2007:11:31:03 +0200] [Job 125614] argv[2]="root"
   D [18/Jul/2007:11:31:03 +0200] [Job 125614] argv[3]="cupsd.conf-kp.2007-07-17"
   D [18/Jul/2007:11:31:03 +0200] [Job 125614] argv[4]="1"

It looks like the job is now being processed nevertheless -- this time
under the credentials of the root user (who did run the original "lp
-U .." command).

My question is this:

   ====================================================================
   Is this caused by the 'cupsdSendError: 7 code=401 (Unauthorized)'
   response which makes the lp client command to re-submit the job, but
   this time as the real user? -- If so, is this a bug or is it "by
   design" (probably required for IPP-compliancy?)?  -- If it is a bug,
   I'll submit an STR...
   ====================================================================


-- 
Kurt Pfeifle
System & Network Printing Consultant ---- Linux/Unix/Windows/Samba/CUPS
Infotec Deutschland GmbH  .....................  Hedelfinger Strasse 58
A RICOH Company  ...........................  D-70327 Stuttgart/Germany




More information about the cups mailing list