Bug 608

Summary: Can't print on Debian/CUPS due to error 'Xprt_64: lpr: unable to print file: server-error-not-accepting-jobs'
Product: xprint Reporter: Jonathan Walther <krooger>
Component: Server: Spooler support: CUPSAssignee: Roland Mainz <roland.mainz>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: highest CC: alan.coopersmith, dparsons
Version: unspecified   
Hardware: x86 (IA32)   
OS: Linux (All)   
URL: http://reactor-core.org/religion/ezekiel.html
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 632    
Attachments:
Description Flags
setuidforktest.c testcase
none
setuidforktest_initgroups_test1.c testcase
none
setuidforktest_initgroups_test1.c testcase
none
Patch for 2004-05-07-trunk
none
Patch for 2004-07-16-oldcvs_trunk (X11R6.6) none

Description Jonathan Walther 2004-05-07 17:13:36 UTC
May  6 23:37:11 debian Xprt_64: lpr: unable to print file:
server-error-not-accepting-jobs
May  6 23:59:42 debian Xprt_64: lpr: unable to print file:
server-error-not-accepting-jobs
May  7 00:02:04 debian Xprt_64: lpr: unable to print file:
server-error-not-accepting-jobs
djw@debian:~$ lpq
SPARCprinterE is ready and printing
Rank    Owner   Job     File(s)                         Total Size
active  djw     104     mozilla.ps                      17799168 bytes
djw@debian:~$ mutt -y
7851 kept, 10 deleted.
djw@debian:~$ 

Xprt correctly detects my SPARCprinterE under CUPS.  The user I run Mozilla as
has the correct permissions to invoke lpr and successfully invokes lpr from the
command line to print things.  But when I try to print to SPARCprinterE@:64
inside Mozilla, Mozilla generates PostScript (I think), then nothing gets sent
to the printer.  Or rather, 1 time out of the 4 tests I did, something DID get
sent to the printer, but I couldn't duplicate it and don't know why it did it
the one time.
Comment 1 Roland Mainz 2004-05-08 09:54:16 UTC
If I understand Jonathan's problem on IRC correctly the CUPS version of "lpr"
cannot forward the print jobs to the CUPS deamon because it isn't in the "right"
Unix group when it is being launched.

I guess the problem is that Xprt - running as "root" - calls |setuid()| before
running the spooler application (e.g. "lpr"). All attach a small test program as
demonatration...
Comment 2 Roland Mainz 2004-05-08 09:58:23 UTC
Created attachment 274 [details]
setuidforktest.c testcase

Test case "setuidforktest.c" to demonstrate the problem (this is a cut-down
version of the code in xc/programs/Xserver/Xprint/attributes.c).

In my test environment by group memberships look like this:
% /usr/bin/id
uid=500(gismobile) gid=2306(gisburn)
groups=2306(gisburn),14(uucp),16(dialout),17(audio),33(video),300(mozilla),100(users),8000(xprint)

-- snip --
... but when I run the example application as user "root" the output of
/usr/bin/id looks like this:
-- snip --
# ./a.out 
child: Setting uid=500
uid=500(gismobile) gid=0(root) groups=2306(gisburn)
-- snip --
All groups (except the primary one) are missing which leads to the problem that
Unix/Linux systems which require an extra group membership for printing won't
work.
Comment 3 Roland Mainz 2004-05-08 10:30:14 UTC
Created attachment 275 [details]
setuidforktest_initgroups_test1.c testcase

setuidforktest_initgroups_test1.c - an attempt to use initgroups() to fix the
problem (per Alan's suggestion)
Note that I added a |system()| call after |setuid()|.
The output (starting it as "root") looks like this:
-- snip --
# ./a.out 
child: Setting uid=500
uid=500(gismobile) gid=2306(gisburn)
groups=2306(gisburn),14(uucp),16(dialout),17(audio),33(video),300(mozilla),100(users),8000(xprint)

uid=500(gismobile) gid=2306(gisburn) groups=2306(gisburn)
-- snip --
The 2nd line of the output is from the |system("/usr/bin/id")| call - this is
how it should be...
... but the 3rd line is from the |execv("/usr/bin/id", NULL)| call - which is
still not correct.

It seems that |execv()| kills any extra groups (except the primary one) ... ;-(


Does anyone have an idea how to solve that problem ?
Comment 4 Roland Mainz 2004-05-08 10:36:58 UTC
Created attachment 276 [details]
setuidforktest_initgroups_test1.c testcase

Sorry, I attached the wrong version... this is the correct one...
Comment 5 Roland Mainz 2004-05-08 11:32:13 UTC
I tested the problem on Solaris and the |execv()| call failed. It seems that the
2nd argument (the parameter array) must not be NULL. Fixing that also gets the
non-primary groups working... :)
Comment 6 Roland Mainz 2004-05-08 11:32:49 UTC
s/Fixing that also gets the non-primary groups working/Fixing that also gets the
non-primary groups working on Linux/
Comment 7 Roland Mainz 2004-05-08 12:03:17 UTC
Created attachment 277 [details] [review]
Patch for 2004-05-07-trunk
Comment 8 Roland Mainz 2004-05-08 12:07:53 UTC
Patch checked-in into trunk...

Checking in xc/ChangeLog;
/cvs/xorg/xc/ChangeLog,v  <--  ChangeLog
new revision: 1.21; previous revision: 1.20
done
Checking in xc/programs/Xserver/Xprint/attributes.c;
/cvs/xorg/xc/programs/Xserver/Xprint/attributes.c,v  <--  attributes.c
new revision: 1.3; previous revision: 1.2
done
Mailing the commit message to xorg-commit@pdx.freedesktop.org...

... marking bug as FIXED.
Comment 9 Roland Mainz 2004-05-08 12:08:32 UTC
Drew:
Can you include the fix into the Debian version of Xprt, please ?
Comment 10 Roland Mainz 2004-05-17 11:48:13 UTC
Created attachment 296 [details] [review]
Patch for 2004-07-16-oldcvs_trunk (X11R6.6)

The patch is for the old X11R6.6-based trunk for those vendors who need it (and
for the 009.001 maintaince release).
Comment 11 Roland Mainz 2004-05-17 11:50:23 UTC
attachment 296 [details] [review] checked-in into oldcvs-trunk:

Checking in xc/programs/Xserver/Xprint/attributes.c;
/cvs/xprint/xprint/src/xprint_main/xc/programs/Xserver/Xprint/attributes.c,v 
<--  attributes.c
new revision: 1.6; previous revision: 1.5
done

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.