Path: utzoo!attcan!uunet!mcvax!ukc!acorn!moncam!harry
From: harry@moncam.co.uk (Jangling Neck Nipper)
Newsgroups: comp.unix.questions
Subject: When is set[re]uid() effective? (When's a UID not a UID?)
Keywords: setreuid,su <<#,chmod 06755,rpc.pcnfsd,lpr,lpd
Message-ID: <HARRY.89Jul4232144@marvin.moncam.co.uk>
Date: 4 Jul 89 22:21:44 GMT
Sender: harry@moncam.co.uk
Distribution: all
Organization: Monotype ADG, Cambridge, UK.
Lines: 56

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?