Okay, so it's been a while since I last touched LPRng. But one of my
former co-workers at MIT asked me to come help figure out why the
later version of LPRng they'd imported wouldn't work in the same
environment as the one I'd last set up.
After a hair-tearing evening or three, we're still hard-pressed to
figure out whether the fault lies in semantic changes of the tokens in
lpd.perms or the segfault caused when reading the "AUTHFROM" lpd.perms
tag.
With our 3.6.1-based servers, we use lpd.perms files such as the
following:
------------------------------------------------------------------------
# Allow anybody to connect, get status, list queue, or print (once a
# job is spooled)
ACCEPT SERVICE=X,S,Q,P
ACCEPT LPC=status,lpq,printcap
# Only trust certain host keys to forward jobs/commands
REJECT AUTH=FWD PRINTER=</var/spool/printer/queues.secure NOT
AUTHFROM=</var/spool/printer/hostkeys.allow
REJECT AUTH=FWD AUTHJOB NOT AUTHFROM=</var/spool/printer/hostkeys.allow
# Allow root to control and remove jobs
ACCEPT SERVICE=C,R SERVER REMOTEUSER=root
# Allow admins to control and remove jobs
ACCEPT SERVICE=C,R AUTH=USER AUTHUSER=</var/spool/printer/lpcaccess.top
# Printer-specific LPC ACLs
ACCEPT SERVICE=C,R PRINTER=money,money2 AUTH=USER
AUTHUSER=</var/spool/printer/money/lpcaccess
ACCEPT SERVICE=C,R PRINTER=sipb,meadow2 AUTH=USER
AUTHUSER=</var/spool/printer/sipb/lpcaccess
ACCEPT SERVICE=C,R PRINTER=sipb,sipb2 AUTH=USER
AUTHUSER=</var/spool/printer/sipb/lpcaccess
ACCEPT SERVICE=C,R PRINTER=vln,vln2 AUTH=USER
AUTHUSER=</var/spool/printer/vln/lpcaccess
ACCEPT SERVICE=C,R PRINTER=dagger,dagger2 AUTH=USER
AUTHUSER=</var/spool/printer/dagger/lpcaccess
# Reject jobs from unauthorized users to restricted queues
REJECT SERVICE=R PRINTER=rinter,rinter2 NOT
USER=</var/spool/printer/rinter/restrict.list
REJECT SERVICE=R PRINTER=dagger,dagger2 NOT
AUTHUSER=</var/spool/printer/dagger/restrict.list
# Accept authenticated jobs to all other printers
ACCEPT SERVICE=R AUTH=USER,FWD
# Allow authenticated users to lprm their jobs
ACCEPT SERVICE=M AUTH=USER,FWD AUTHJOB AUTHSAMEUSER
# Reject unauthentic print/lprm requests to authenticated queues
REJECT SERVICE=R,M PRINTER=</var/spool/printer/queues.secure
# Reject unauthentic print requests from off MITnet
REJECT SERVICE=R NOT REMOTEIP=</var/spool/printer/masks.allow
# Accept unauthentic print requests if same user and on MITnet
ACCEPT SERVICE=M NOT AUTHJOB SAMEUSER REMOTEIP=</var/spool/printer/masks.allow
# Reject any other lpc, or lprm. Accept all else
REJECT SERVICE=C,M
DEFAULT ACCEPT
------------------------------------------------------------------------
After much coaxing, we discovered that the reason people could not
lprm their own jobs was that the connection-handling lpd was receiving
a SIGSEGV and exiting. This problem exists in 3.6.13 (our newer
snapshot), and still exists in current code. Here's a stack trace,
from an LPRng 3.6.26 lpd (code unmodified from ftp.astart.com):
------------------------------------------------------------------------
(gdb) where
#0 0x78690 in Find_first_key (l=0x0, key=0x127068 "_", sep=0x126fb8 " \t=#@",
m=0xffbee8c0) at ./common/linelist.c:790
#1 0x79128 in Find_str_value (l=0x0, key=0x127068 "_", sep=0x126fb8 " \t=#@")
at ./common/linelist.c:952
#2 0x70314 in Perms_check (perms=0x1478d0, check=0x147c9c, job=0x0,
job_check=0) at ./common/permission.c:355
#3 0x3aaf0 in Job_control (sock=0xffbef084,
input=0x148c87 "sipb zacheiss start sipb") at ./common/lpd_control.c:118
#4 0x2c5b4 in Dispatch_input (talk=0xffbef084,
input=0x148c86 "\006sipb zacheiss start sipb") at ./common/lpd.c:663
#5 0x4a27c in Do_secure_work (use_line_order=1, jobsize=0x0, from_server=0,
tempfile=0x14e010 "/var/spool/printer/sipb/temp00UKaakP",
header_info=0xffbef258) at ./common/lpd_secure.c:344
#6 0x43140 in Krb5_receive (sock=0xffbef5b0, user=0x149b78 "zacheiss",
jobsize=0x0, from_server=0, authtype=0x150c58 "kerberos", info=0xffbef248,
error=0xffbef2a1 "", errlen=511, header_info=0xffbef258,
tempfile=0x14e010 "/var/spool/printer/sipb/temp00UKaakP")
at ./common/krb5_auth.c:1373
#7 0x49ab8 in Receive_secure (sock=0xffbef5b0,
input=0xffbef670 "\bsipb C zacheiss kerberos") at ./common/lpd_secure.c:217
#8 0x2c5e4 in Dispatch_input (talk=0xffbef5b0,
input=0xffbef670 "\bsipb C zacheiss kerberos") at ./common/lpd.c:669
#9 0x2c44c in Service_connection (args=0xffbefa10) at ./common/lpd.c:636
#10 0x2e4ec in Do_work (args=0xffbefa10) at ./common/lpd.c:1185
#11 0x2e1f8 in Make_lpd_call (passfd=0xffbefa00, args=0xffbefa10)
at ./common/lpd.c:1151
#12 0x2e9fc in Start_worker (parms=0xffbefac0, fd=9) at ./common/lpd.c:1269
#13 0x2baf4 in main (argc=1, argv=0xffbefc9c, envp=0xffbefca4)
at ./common/lpd.c:466
------------------------------------------------------------------------
Any other information needed, just ask.
It also appears that (at least) the semantics of the AUTH tag in
lpd.perms have changed, though it's impossible to verify because the
worker daemons keep dying. This is going to cause us a lot of grief,
since as far as we can tell, there is no single lpd.perms file that
will do what we want in both 3.6.1 and 3.6.13. This makes rolling out
a new version of lpd a nightmare.
So, what's to be done? We're working on tracking down the ultimate
cause of the segv, but if the semantics of lpd.perms have indeed
changed in the patch releases between 3.6.1 and 3.6.13, we may need to
do some significant local modification (to be maintained indefinitely)
to create a set of semantics that works in both versions.
Thoughts and advice will, of course, be appreciated.
Mike Whitson
(volunteering for MIT Athena Server Operations)
-----------------------------------------------------------------------------
YOU MUST BE A LIST MEMBER IN ORDER TO POST TO THE LPRNG MAILING LIST
The address you post from MUST be your subscription address
If you need help, send email to [EMAIL PROTECTED] (or lprng-requests
or lprng-digest-requests) with the word 'help' in the body. For the impatient,
to subscribe to a list with name LIST, send mail to [EMAIL PROTECTED]
with: | example:
subscribe LIST <mailaddr> | subscribe lprng-digest [EMAIL PROTECTED]
unsubscribe LIST <mailaddr> | unsubscribe lprng [EMAIL PROTECTED]
If you have major problems, send email to [EMAIL PROTECTED] with the word
LPRNGLIST in the SUBJECT line.
-----------------------------------------------------------------------------
