2.2 Release immenent/2.0.7 possible print issues

[Samuel Greenfeld]

>>> Jeremy Allison <jeremy at valinux.com> 04/10/01 06:49PM >>>
Samuel Greenfeld wrote:

> 1. While the print job itself is forced to the user, no accessory program used seems
> to do so.   This is a problem with LPRng, given that only certain users may be given
> rights to force the username of a print job, and it is desirable to keep that list as
> small as possible.   Right now, we are living with this, and working around it, but a
> fix to this would be nice.   This activity was verified by temporarily putting a program
> in place of /bin/sh (run by system()) that would log the UID, EUID, GUID, command &
> parameters, etc.

Hmmmm. smbd becomes the user reqesting the print job before
doing the lpr call. What isn't working for you here ?

--   Sorry about being a bit unclear; I meant that all operations *except* the call to lpr itself are not forced to the user.

   An example done from a Win2k workstation.   The numbers are listed in the order UID/EUID/GID/EGID for the sh process.   User #2 is daemon; user #10000 is gree3776.   Group #2 is daemon, #1000 is students.

Apr 11 11:41:41 henry sh[24406]: 2,2,2,2: Running /usr/bin/lpr  -Pece238 -Ugree3776 at 150.250.105.108  -r GREE3776.6a9mKd
Apr 11 11:41:43 henry sh[24415]: 10000,10000,1000,1000: Running /usr/sbin/lpc -Ugree3776 at 150.250.105.108  hold ece238 406
Apr 11 11:41:45 henry sh[24423]: 10000,10000,1000,1000: Running /usr/sbin/lpc -Ugree3776 at 150.250.105.108  release ece238 406
Apr 11 11:41:47 henry sh[24429]: 10000,10000,1000,1000: Running /usr/bin/lprm -Ugree3776 -Pece238 406

   While LPRng will not fail these calls at the local level, the -U parameter gets ignored.   With a "SAMEUSER SAMEHOST" ruleset with lprng, the job put in by lpr where the user and host were specified can not be modified by that user.   Note my solution of sorts at one time was to allow local users (hence the lack of an @IP ) with the same username as a remote one to delete a print job (technically, the -U even without the IP is ignored and was just logged for me, but the UID the process ran as isn't).   Got to look at my notes to figure out exactly what I am doing at the moment :)

   Please *also* check actions for the entire queue (pause/resume/flush/etc.), as I can not do it from this NT box at the moment.   The "lpq" queue listing command also needs to be looked at (due to the number of lpq's I kept logging, eventually I made the executable used ignore them).   A feature that also might be nice to add is the immediate expiration of cached queue data in the event of a control operation or even maybe a print job (although I do not know if any Windows OS requires this, or if this is done already).


> 2. Whenever someone requests the printer's status, samba creates a /tmp/lpq.XXXXX file,
> where XXXXX is a series of eight or so characters.   This file is created as root, but
> is not deleted.   After a while, this leads to a lot of /tmp/lpq.XXXXX files hanging
> around that have to be manually cleared.   A new one seems to be created whenever samba
> feels like refreshing a print queue's status.

Fixed.

-- Noted.

   Another minor bug (#3): granted, this likely is due to my setup, but when setting socket options, my system does not seem to be able to look up what TCP_NODELAY, etc., mean.    Given I run servers pretty much stripped down so nothing bites me securitywise I do not know about, what did I accidentally take out which allows these to be turned into their proper constants?

   And for the documents (#4):  Do different samba printer definitions need different paths like most lpd daemons require?  Or can you define a bunch of printers (or even maybe file shares) pointing to the same path?

   Got to run again... (too many papers due too soon)

   Sincerely,
   Samuel Greenfeld