Re: a follow-up question on permissions

>Message-Id: <199203251928.AA24416@tbird.cc.bellcore.com> >From: uunet!hector.cc.bellcore.com!warren (saccente,warren j) >Date: 25 Mar 1992 13:28 EST >Subject: a follow-up question on permissions >X-Informix-List-Id: <list.998> > >... >Anyway, the program that creates new databases grants dba to public >because, theoretically, any user might be deleting the database (security >is handled by the application). >... >Here's the problem, even though users are not suppose to use isql, they do >and we are told that we must allow them. Then you cannot have any security. There is, regrettably, not much point in trying to discuss the matter any further. ISQL does not use anything other than the basic database security features. You have had to give public DBA permission, so you are saying that if the user can get at the database, you don't mind what the user does because the user is responsible enough not to do any damage! This is undoubtedly incorrect, but that is what the DBA privilege implies. >My first workaround was to change to effective user of the programs that >create/delete dbs/tables by running chmod 6755 on those executable. This >should have made informix think that the owner of the executable was the >user at run time and that login would be the dba/creator. This did not work, >apparently informix uses the real user rather than the effective. We are >running att universe, so you can only change the real user if you are root. I sent this e-mail to someone in Informix to explain this phenomenon: * Date: Tue Nov 26 08:01:41 1991 * From: johnl (Jonathan Leffler) * To: kellyt@cheetah * Subject: Re: Real vs. Effective UID * * >From: kellyt@cheetah (Kelly Todd) * >Message-Id: <9111251819.AA12081@cheetah.informix> * >Subject: Real vs. Effective UID * >To: tech@cheetah * >Date: Mon, 25 Nov 91 10:18:59 PST * > * >Hi Tech, * > * >I have a customer that asks: * > Why do our products use REAL uid instead of EFFECTIVE uid? * > * >I know how to get around it be calling setuid(), but does anyone know the * >reasons behind why we do it the way we do. * * Are you sure? * * First points first: * 1. The database engine accesses the database. * 2. The database engine starts with SUID root and SGID informix permissions. * -- the root privileges are used to adjust some system limits. The user * ID is then set back to the real UID. * 3. The database engine runs with SGID informix permissions. * * Let's look at what happens when an engine is started (UID/GID only). * 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. * The 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. * * Jonathan Leffler (johnl@asterix) * * Date: Tue, 26 Nov 91 16:24:42 GMT * From: johnl@obelix (Jonathan Leffler) * Message-Id: <9111261624.AA19047@obelix.informix.com> * To: kellyt@cheetah * Subject: Re: Real vs. Effective UID * * To cut a long story short: * * > situid() * > { * > retlong((long) setuid(geteuid())); * > return 1; * > } * * On real Unix (not BSD), this will only work if the EUID = 0 (root)! * And that's not so very helpful, really. (I believe that BSD behaves * the same way -- it's a potentially enormous security hole otherwise!). * * Yours, * Jonathan Leffler (johnl@asterix) * * Date: Tue, 26 Nov 91 11:47:47 PST * From: aland@quasar (Alan Denney) * To: kellyt@cheetah * Subject: Re: Real vs. Effective UID (fwd) * * >> From: kellyt@cheetah (Kelly Todd) * >> Subject: Re: Real vs. Effective UID (fwd) * >> To: aland@cheetah (Alan Denney) * >> Date: Tue, 26 Nov 91 8:36:34 PST * >> * >> As the contact of TechInfo #481, would like to make any comments on * >> whether this example will work? I am getting some responses back from my * >> email that maybe this article is inaccurate, or incomplete. * > * >Date: Tue, 26 Nov 91 16:24:42 GMT * >From: johnl@obelix (Jonathan Leffler) * >Message-Id: <9111261624.AA19047@obelix.informix.com> * >To: kellyt@cheetah * >Subject: Re: Real vs. Effective UID * >... * * It's incomplete in the sense that it doesn't tell you how to USE it. * * The key difference with System V vs. BSD is that System V doesn't let you * change your real uid unless you are already effectively root (euid == 0). * So, the executable file *must* be owned by root for System V. For BSD, * it can be owned by root -or- by the uid you want to end up as (e.g. informix). * * aland You could therefore write a SUID root program that set its real (and effective) UID to some special user before it ran the CREATE program. This would work entirely satisfactorily provided that you can be confident that the SUID root program cannot be tampered with by unauthorised users. >I thought of updating the system catalog tables dynamically after the db/tables >are created but didn't think I'd have permission. Surprisingly, I was able >to update sysusers (an informix bug?) but was not able to update systables. You can update systables as user informix in 4.00 and later; you can do it as informix or as the creator of the database in 2.10.03 and earlier. If you mess it up, it's your problem. Yours, Jonathan Leffler (johnl@obelix.informix.com)