When is set[re]uid() effective? (When's a UID not a UID?)

[Lori Corrin]

In article <HARRY.89Jul4232144 at marvin.moncam.co.uk> harry at 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 at hadrian.uwo.ca
  University of Western Ontario			purple at uwovax.BITNET
  London, Ontario, Canada