Re: Question on Access Privileges

>From: uunet!pyra.co.uk!graeme (Graeme Sargent) >Subject: Re: Question on Access Privileges >Date: Fri, 25 Jun 1993 10:43:06 GMT >X-Informix-List-Id: <news.3646> > >johnl@obelix.informix.com (Jonathan Leffler) wrote: >>>From: uunet!iti.gov.sg!cmlow (Low Chee Meng) >>>Subject: Question on Access Privilleges >>>Date: Thu, 24 Jun 1993 04:26:27 GMT >>>X-Informix-List-Id: <news.3630> > >>>2) If I have an ESQL/C program that has the SET_UID bit set, will whoever >>>that runs this program have the same access privileges as me? In other >>>words, does Informix check the REAL user-id or the EFFECTIVE user-id when >>>checking for access violations? > >>It could use either, but the two user IDs are always the same. > >>Both Informix-OnLine and Informix-SE are themselves SUID root, SGID >>informix programs. When the engine is run, these setXid privileges >>effectively lose the SUID-ness (and SGID-ness) of the program which runs >>the engine. The application real and effective IDs are not changed, of >>course, because they are a separate process from the engine process. > >>The root privileges are used briefly to set ulimit to infinity (or near >>enough), and then the effective UID is reset to the real UID. The group > ^^^^^ >>informix privileges are retained and are the normal source of access rights >>on the database tables. Hence, no-one except user informix should belong >>to group informix. >But the effective UID was NOT previously the real UID, so can you >reconfirm that the effective UID is *set* to the real UID and not >*reset* to the effective UID of the calling process? > >I thought it did the latter, (although I haven't checked). And I think >I think that it *should* do the latter. This is to confirm that it gets reset to the REAL UID. The engine cannot set the effective UID back to the previous effective UID because it has no idea (and cannot find out) what the previous effective UID was. The following message should go into the mythical FAQ, because it is not the first time I've had to explain it... Date: Tue Nov 26 08:01:41 1991 From: johnl (Jonathan Leffler) Subject: Re: Real vs. Effective UID >From: kellyt@cheetah (Kelly Todd) >Subject: Real vs. Effective UID >Date: Mon, 25 Nov 91 10:18:59 PST > >I have a customer that asks: > Why do our products use REAL uid instead of EFFECTIVE uid? First points first: 1. The database engine accesses the database. 2. The database engine starts with SUID root and SGID informix permissions: call this Phase I. The root privileges are used to adjust some system limits. 3. The user ID is then set back to the real UID: call this Phase II. 4. The database engine runs with SGID informix permissions. Let's look at what happens when an engine is started by an application which is not running SUID or SGID. Lets assume informix is UID 100 and GID 100. UID EUID GID EGID APPLICATION: 379 379 256 256 ENGINE PHASE I: 379 0 256 100 ENGINE PHASE II: 379 379 256 100 So far, so good; the system could use either the real UID or the effective GID. Now, lets use a SUID application; for good measure, we'll make it SGID too, with SUID = 500 and SGID = 500. UID EUID GID EGID APPLICATION: 379 500 256 500 ENGINE PHASE I: 379 0 256 100 -- At this point, the engine has lost any information about the SUID/SGID of the application! ENGINE PHASE II: 379 379 256 100 -- At this point, the possible UIDs are 379 (the real user) or 0 (root). -- We certainly don't want to run as root! Problem: the engine never gets to see either SUID or the SGID of the application. The problem is fundamental to Unix; SUID program A cannot run SUID program B and have the effective privileges of the SUID user of program A. Summary: you always have to use the real UID in the database. Note that the saved-UID (saved-GID) values in POSIX-compliant systems do not help. Even on BSD-type systems which support setruid, seteuid, setrgid and setegid, the information which is needed simply isn't available. To make it available, Unix would have to be rewritten to maintain a stack of UID/GID values. There would then be the need for things like login to be able to remove privileges from the stack (so an arbitrary user program could not accidentally re-acquire root privileges), and so on. Yours pedagogically, Jonathan Leffler (johnl@asterix)