New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LPD backend filter can get in an infinite loop if rresvport() fails #752
Comments
CUPS.org User: mike I'm not keen on changing to use geteuid(), since it is not universally available and the code is specifically designed to either run as root or not (no setuid stuff); it sounds like you are running the parent process as root but are running the backend as an unpriviledged user??? Is there a particular reason why you are doing this, and wouldn't passing the reserve=no option be a simpler solution? |
CUPS.org User: speter.codehost As far as I know geteuid() is available anywhere getuid() is, at least on Unix platforms. As I said, we are not running this filter in a regular cupsd environment. The AIX LP spooler runs printing scripts as the user who submitted the job (thus does a seteuid() somewhere along the way). This confuses this filter if you are not checking for the effective UID, and triggers an infinite loop trying to reserve the port (which at least should really be fixed one way or another). Using geteuid() is the quick fix for us. We want to give the user the ability to use the 'reserve' option at will, so both cases should be able to work nonetheless. |
CUPS.org User: mike I added a configure-time check for geteuid() and we use it instead of getuid() in the LPD backend when it is available. |
CUPS.org User: mike Fixed in CVS - the anonymous CVS repository will be updated at midnight EST. |
"lpd.c.patch": Index: backend/lpd.cRCS file: /home/anoncvs/cups/backend/lpd.c,v
|
Version: 1.1-current
CUPS.org User: speter.codehost
I noticed that the lpd filter (on AIX) was locking up trying to secure a reserved port. The rresvport() function was failing and returning a "No permissions" error. It would then enter in an infinite loop trying to get a port, but would never manage to get one.
Note that this is not run from within CUPS itself, but rather from our BrightQ software, which runs inside the original SystemV printing system as a print filter, so this is a rather unusual environment, and likely cupsd wouldn't exhibit this problem.
I tracked down the cause of the problem to the incorrect use of getuid() instead of geteuid() to determine if the user is root or not. The attached patch fixes this.
The text was updated successfully, but these errors were encountered: