Can't access spool folder

[Helge Blischke]

Daniel Stoeck wrote:

>> Daniel Stoeck wrote:
>>
>> > Hi there,
>> >
>> > I am using Helge Blischke's prtofile backend and when I try to print I
>> > get an error message like this: "/private/var/spool/cups/c00061: No
>> > such file or directory"
>> >
>> > /private/var/spool/cups has 710 permissions and belongs to root:_lp
>> > /private/var/spool/cups/c00061 has 600 permissions and belongs to
>> > root:_lp (61 is the jobid)
>> >
>> > Obviously the printer cannot spool into its spool directory. But how
>> > can I avoid this permission issue?
>> >
>> > The backend has 700 permissions to make it run as root.
>> > The Device_URI is "prtofile:///Volumes/MacHD/output/ps/"
>> > The given PPD is the common Adobe Distiller PPD
>> >
>> > Why does the printer not have permission to write into its spool
>> > folder? Can I just change the permissions of the spool folder to
>> > anything else to fix this?
>> >
>> > Greetings from Germany,
>> > Daniel
>>
>> Hi Daniel,
>>
>> I suppose on Snow Leopard, CUPS and/or components of it are running in a
>> sandbox.
>> Search your system for things like cupsd.sb or xxx.sb (xxx the name of
>> one of the standard backends of CUPS) and use that as a template for a
>> sandbox profile for prtofile. The current version needs read access to
>> the CUPS spool directory to get the value of the job-originating-hostname
>> attribute.
>>
>> If you are not sure what to do, you could mail the sb files of interest
>> for me to look into.
>>
>> Helge
>>
> 
> Hi Helge,
> 
> I found /usr/share/sandbox/ as the default folder for sandbox profiles on
> my Snow Leopard Server. There are several *.sb files in this folder, but I
> cannot identify one that belongs to cups. (to duplicate it for the custom
> backend).
> 
> A list of all *.sb profiles I found:
> 
> bsd.sb
> mDNSResponder.sb
> quicklookd-job-creation.sb
> xgridagentd_task_nobody.sb
> cvmsCompAgent.sb
> mds.sb
> quicklookd.sb
> xgridagentd_task_somebody.sb
> cvmsServer.sb
> mdworker.sb
> serialnumberd.sb
> xgridcontrollerd.sb
> fontmover.sb
> named.sb
> sshd.sb
> kadmind.sb
> ntpd.sb
> syslogd.sb
> krb5kdc.sb
> portmap.sb
> xgridagentd.sb
> 
> Do I just need read access to the parent directory of my spool folder?
> Nothing else?
> 
> Daniel

Well, I downloaded the sources of 1.4.x (1.4.4 in fact) and found (thanks to 
a post of Michael Sweet somewhere else) that the scheduler itself generates 
a fairly restrictive sandbox profile for every filter/backend subprocess it 
forks.
This profile permits reading the data file in the spool directory but not 
the control file.

So there are three alternatives to settle down that issue:
(1)	Adding the commandline option "-P" in 
	/System/Library/LaunchDaemons/org.cups.cupsd.plist
	(which disables sandboxing completely but is not recommended)

(2)	Recompiling CUPS freom the sources after modifying the file
	scheduler/process.c
	accordingly (be sure to configure the compilation process as to 
	compile both architectures (i386 and ppc) and replace only the cupsd
	executable (all other stuff unchanged).

(3)	Wait a couple of days for an updated version of my backend that no 
	longer reads the control file but links to libcups.dylib (via the Perl
	inline package, which needs to be installed separately).

As for the target directories, I'd recommend to write to a directory tree 
under "/private/", which seems to be permitted, and either move the data to 
the final destination by a postprocessing command or by setting symbolic 
links appropriately.

Let me know which of these solution you prefer (for me to be able to adjust 
my time schedule accordingly).

Helge