CUPS Backend permission changes?

I am not sure if this is the right forum, as I don't understand yet, if this is a cupsd specific change/problem or a general change with daemons.

Some of my clients report that our custom CUPS backend doesn't work anymore since upgrading to Leopard.

About the backend: It's a very simple C application that creates parameter for a lpr like command-line tool based on a printer's Device-URI. It also looks for a hidden file in the User's home directory to find his network-ID. It does require root access to read that file.

Now under Tiger and earlier versions this worked fine, even with the backend being world-readable.
Now to get this thing working under Leopard, some users require the backend, the command line tool and the user's ID file to be owned by root, and set to root access only.

It seems cups backends running as root do not have access to anything, not owned and exclusively accessible by root anymore.

Does anyone know what kind of setting or change this could be?

Mac Book Pro, Mac OS X (10.5.1)

Posted on Dec 3, 2007 1:29 AM

Reply
6 replies

Dec 3, 2007 9:14 AM in response to Alain Haegi

I am having a printing problem also and I wonder if it's related to these permission changes. Here's what I observe when attempting to print from Java applications to a printer attached to a Windows print server. I have no problems printing from normal applications, but problems with both web start and regular Java applications (e.g. JEdit).

1. As admin user. The print queue dialog appears, the print job is set to run as "System Administrator". The job Status is "On Hold (Authentication Required)". If I click the Resume button I get prompted for my (Windows) username and password, after that the print job goes through normally. If I create a custom print queue (using the Advanced setup) of this form: "smb://windowsUsername:password@printServer:port/Printer" then the java application will print without requiring further confirmation in the Print queue dialog.

2. As a standard user. The java application presents a modal dialog that indicates a printing failure. The dialog does not get dismissed after clicking the OK button, but does close when the java application is quit. I have not found any work arounds that allow standard users to print.

Dec 3, 2007 9:43 AM in response to Alain Haegi

This is a cupsd change that happened in CUPS 1.2. Since Leopard comes with CUPS 1.3.x, it inherited the change.

Basically, in the CUPS 1.1.x (pre-Leopard) days, all backends were run as root. This had some unfortunate security implications, so in 1.2 we changed cupsd to only run backends as root when they did not have world read/execute permissions, otherwise they run as the unprivileged user "lp" (actually "_lp" on Leopard...)

Since earlier releases of CUPS did not care about world-read permissions, you can install your backend with the same (restricted - mode 0700 or 0500) permissions on all Mac OS X releases and get the same behavior.

That said, you generally should not be reading files from the user's home directory since the print job can come from anywhere, not just the local system. The printing user may not have a local account or home directory you can read!

Dec 4, 2007 11:38 PM in response to cupsguy

The thing that confuses me, is that world readable affects it. I can understand worldwritable from a security perspective.
Btw, the backend man says:
"Backends without world execute permissions are run as the root user. Otherwise, the backend is run using the unprivileged user account, typically 'lp'."

I am aware that jobs could come from an other box, the backend simply uses the given username if there is no home.

The whole "hack" with checking the user's home comes from problems with usernames. So far i was unable to find anyway a user can edit the name with which his print jobs are sent to the local cuspd.
And this again is a problem, because all our backend does is send the printjob from cups to our uni's custom print server (our own software, in-house development), for administrative reasons we need the user's network name, and not his local username.

I could keep a "translation table" or something in /etc that maps localusernames to networknames or something like that, but i simply didn't want anything that requires root access.

Guess it's time to rework the backend and find an other solution.

Message was edited by: Alain Haegi

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

CUPS Backend permission changes?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.