harry@moncam.co.uk (Jangling Neck Nipper) (07/05/89)
I'm running SunOS 4.0.1 on a Sun 3/160 and I am attempting to run a
program (rpc.pcnfsd (1.4) to any who've heard of it; it's the daemon
that lets PC's access NFS file systems, and spool print jobs), and
I've made it set uid/gid to root. This is because it is meant to call
execlp() on /usr/ucb/lpr, previously calling setreuid() and setregid()
with values appropriate to the calling user, so lpr thinks it was
called by that user. However, I find that unless rpc.pcnfsd is called
thus:
up <anybody> rpc.pcnfsd -d
(-d for debug mode; see later) where `up' is a shell script:
: up user command
: - execute command as another user e.g. up bin make install
if test $# -le 1
then
echo "usage: up user command"
exit 0
fi
USER=$1
shift
if test $USER = yours
then
USER=root
fi
su $USER <<!
$* < /dev/tty > /dev/tty
!
The lpr job will be owned by whoever invoked rpc.pcnfsd. Note that it
really *is* <anybody> who can be made to do it - not root or the person
who you want the setreuid() and setregid() to be set for, so I suppose
it's the act of calling this script from inside a shell, since doing:
su root
su <<#
rpc.pcnfsd -d
#
won't work either (it *still* thinks it's me). I know that the real
and effective id's are meant to have been set up, but I'm not very
convinced. To add to the mystery, if I just run rpc.pcnfsd straight,
the setreuid() and setregid() calls both work, but if I use the `up'
script mentioned above, even if it's `up root rpc.pcnfsd -d', the
setregid() call will fail. That is maybe another matter, but it makes
me wonder if the set uid/gid stuff is all it's cracked up to be. I
had a similar problem in SunOS 3.4 (I think) whereby using your own
input filter in /etc/printcap caused lpd to bomb out with:
permission denied: restarting filter
or some such error, UNLESS you actually *logged in* as root and ran
lpd; doing `su' followed by lpd wasn't good enough, but what puzzles
me still (we're now running 4.0.1) is that surely *surely* lpd was run
from rc.local as root???? (to confuse the issue further, if I login as
root and run rpc.pcnfsd -d, I get jobs spooled as root, as the setregid()
call *still* fails).
Note that when the rpc.pcnfsd is run up from rc.local, the name of the
user who *seems* to be doing the remote print from a PC is
*completely* arbitrary, but *always* the same (uid 9). Also, given
that my invocations of rpc.pcnfsd were debug ones, when the parent
doesn't quit, if I then call it in its daemon mode, whereby it forks
off a child and the parent exits, all subsequent jobs *no matter what
I do* are owned by this mysterious No. 9; I assume this will be
something to do with the child being inherited by /sbin/init.
Any ideas?purple@hadrian.uwo.ca (Lori Corrin) (07/07/89)
In article <HARRY.89Jul4232144@marvin.moncam.co.uk> harry@moncam.co.uk (Jangling Neck Nipper) writes:
I'm running SunOS 4.0.1 on a Sun 3/160 and I am attempting to run a
program (rpc.pcnfsd (1.4) to any who've heard of it; it's the daemon
that lets PC's access NFS file systems, and spool print jobs), and
I've made it set uid/gid to root. This is because it is meant to call
execlp() on /usr/ucb/lpr, previously calling setreuid() and setregid()
with values appropriate to the calling user, so lpr thinks it was
called by that user. However, I find that unless rpc.pcnfsd is called
thus:
<lots deleted>
Any ideas?
Well we ran into a similar problem here that may be relevant. Sun's
version of lpd is broken. When we ran pcnfsd the print jobs always
came out with the name of the user that was logged into the console.
lpr searchs /etc/utmp for some unknown reason. If the print job was
started by a daemon (ie rpc.pcnfsd) or by a user who was not recorded
in /etc/utmp (ie rsh) the the lpd control file will contain P and L
fields with the name of the user currently logged into the console. If
there is no user logged into the console it will believe what it was
told. The problem really shows up with PC/NFS where pcnfsd will setuid
to that of the requesting user. It can be duplicated without going
through pc-nfs as follows.
1) Log into the console as 1 user
2) su to another user
3) lpr -r -s -Pprinter "-J " -Csomeplace filename
#this is how pcnfsd invokes lpr
Your job should print as the second user. It doesn't you'll end up
with the name of the person on the console.
to fix it we ended up replacing lpr.
Lori Corrin
Computing and Communications purple@hadrian.uwo.ca
University of Western Ontario purple@uwovax.BITNET
London, Ontario, Canada