newsuser@LTH.Se (LTH network news server) (10/24/88)
PLP - The Public Line Printer Spooler Have anyone (maybe the author) tried this in sunOS 4.0? I've succeded with this 'almost'. The first problem is that setreuid have changed. If you not is ruid root or the same ruid as euid you can't set back euid to root. This I fixed with setreuid(0, -1) in a few strategic places. But I've still problems with statd and lockd. I've a NFS mounted spool directory. This works fine. But lpd hangs when it starts up in /etc/rc. (Yes, I changed the removal of lockfile) If anyone fixed this I would be very happy to know. -- ============================================================================== Joergen Haegg jh@efd.lth.se System manager @ efd 046-107598 Lund Institute of Technology Sweden ==============================================================================
guy@auspex.UUCP (Guy Harris) (11/01/88)
> Have anyone (maybe the author) tried this in sunOS 4.0? > > I've succeded with this 'almost'. The first problem > is that setreuid have changed. If you not is ruid root or > the same ruid as euid you can't set back euid to root. Umm, that's the way it is in 4.3BSD; the only way to set the euid back to "root" is if the ruid is "root" (or the euid is already "root", but so what). SunOS extends this, System V-style, so that you can also do it if the saved set-user ID is also "root". The saved set-user ID is set when: 1) you do an "exec" of a set-UID program - it's set to the ID to which the program is set-UID 2) you do a "setreuid" that explicitly sets the real UID (i.e., the first argument is not -1) - it sets the saved set-user ID to the new real UID ("setruid" and "setuid" do this, unless of course the argument is -1, but passing -1 to either of those routines is a no-op) or under 4.0, you do a "setreuid" that sets the effective UID unequal to the real UID - it sets the saved set-user ID to the new effective UID (the reasons for this are complicated, but basically have to do with making the new rules for "kill" work right). Note that if you set the effective UID equal to the saved set-user ID, this obviously makes no difference, so the only place where it should make a difference is if you set the effective UID equal to *neither* the saved set-user ID *nor* the real UID - which you can only do if the effective UID is "root". Basically, the saved set-user ID stuff was only intended to be used by a set-UID process switching its effective UID between its real UID and its original (saved) set-user ID; it was not indended to be used by some set-UID "root" program to switch amongst several UIDs. If you want that, the set-UID "root" program should first set its real UID to "root", and then switch its effective UID from "root" to one new UID, and then back to "root", and then to the other UID, and then back to "root", etc.. This should work under vanilla 4.[23]BSD, not just under SunOS. (Obviously, a program set-UID to user A can't switch the UID to any UID other than A or the real UID, so *only* a set-UID "root" program can do this kind of arbitrary switching - at least not on a system that isn't trivial to break into....) Now, as far as I know, the SunOS 3.x and 4.0 rules let you do any "setreuid" call that 4.3BSD would have; as such, PLP could just use the BSD code when running under SunOS. Maybe Patrick Powell (his middle initial wouldn't be "L", would it?) wanted to use the extra functionality of the SunOS "setreuid", but unless it makes something work better than it did under 4.3BSD, it doesn't seem worth it to do so - just stick with the BSD code. The assertion in the comment for the "Clear_uid" routine in the version I have says: * set UID back to normal. Note that there are two versions of setreuid * available. The VAX 4.2/4.3 version allows you to swap RUID/EUID * and will allow you only to set your UID if you are EUID root. * The SUN 3.X and others will allow you ONE call to the SUID function, * and will allow you to set the UID back to the original. The * uid_parm flag determines which strategy to use. * If uid_parm is -1, then you have to use setreuid( -1, euid ) * If it is not, then we have to swap the EUID/UID, then set * the UID and EUID explicitly As far as I know, the Sun 3.x version will let you do *anything* the VAX 4.2/4.3 version will do - I have the code to the SunOS 3.x, SunOS 4.0, and 4.3BSD versions, and they sure indicate that the 3.x and 4.0 versions will let you do anything the BSD versions will. Thus, the VAX 4.2/4.3 strategy will work as well under SunOS as it will under VAX 4.2BSD/4.3BSD. The SunOS strategy may work better under SunOS than does the VAX 4.2BSD/4.3BSD strategy, but I presume the VAX 4.xBSD strategy works well enough....