Skip to content
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

Closed
michaelrsweet opened this issue Jun 8, 2004 · 5 comments
Closed
Labels
enhancement New feature or request
Milestone

Comments

@michaelrsweet
Copy link
Collaborator

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.

@michaelrsweet
Copy link
Collaborator Author

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?

@michaelrsweet
Copy link
Collaborator Author

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.

@michaelrsweet
Copy link
Collaborator Author

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.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: mike

Fixed in CVS - the anonymous CVS repository will be updated at midnight EST.

@michaelrsweet
Copy link
Collaborator Author

"lpd.c.patch":

Index: backend/lpd.c

RCS file: /home/anoncvs/cups/backend/lpd.c,v
retrieving revision 1.63
diff -u -r1.63 lpd.c
--- backend/lpd.c 13 May 2004 15:13:42 -0000 1.63
+++ backend/lpd.c 8 Jun 2004 02:24:48 -0000
@@ -605,7 +605,7 @@
else if (lport < 1)
lport = 1023;

  •  if (getuid() || !reserve)
    
  •  if (geteuid() || !reserve)
    
    {
    /*
    • Just create a regular socket...

@michaelrsweet michaelrsweet added the enhancement New feature or request label Mar 17, 2016
@michaelrsweet michaelrsweet added this to the Stable milestone Mar 17, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant