Re: Non DBA UPDATE STATISTICS

On Wed, 9 Sep 1998, Art Kagel wrote: > On the other hand if you call setuid(0) then setuid(userid) then fork and The call to setuid(0) will only work if the program is SUID root -- which makes the program a considerably bigger risk than an ordinary SUID non-root program. I see no mention of root in your message, so I treated SUID program as the general case, not the specific SUID root case. If the EUID is 0, then the setuid(uid) call sets both real and effective UIDs without needing a second call. > exit the child process's real AND effective userid will be set. This is > trivial code and does not require any user to know the Informix or DBA > user's password. I was trying (but probably failed) to say that the password in question should be none of the normal passwords but a password explicitly for the non-DBA updstat program. Specifically, it should not be either the Informix or the DBA user's password. The approach I suggested doesn't even require a SUID program; if the user knows the password for the program, then they can use the program, and the program uses the secret DBA password and keeps it carefully obscured in its object code so that it is hidden from the casual onlooker. Yours, Jonathan Leffler (jleffler@informix.com) #include <witticism.h> Guardian of DBD::Informix v0.60 -- http://www.perl.com/CPAN Informix IDN for D4GL & Linux -- http://www.informix.com/idn PS: Sorry to get hung up on all this, but SUID programs are in general dangerous, and SUID root programs are even more extremely dangerous. It is worth avoiding them if at all possible. > ---- Original Msg from: Jonathan Leffler <jleffler@informix.com> At: 9/ 8 18:5 > > On Tue, 8 Sep 1998, Art S. Kagel wrote: > > sanjeev sagar wrote: > > > There are two user id, user x and user y. User x owns > > > the database and tables. There is a requirement that > > > user y should run the UPDATE STATISTICS. > > > > > > I did check that for running the update statistics, > > > it has to have DBA priviledge, even for giving SET > > > SESSION AUTHORIZATION. > > > > > > B'coz of security reason i can not grant DBA to User > > > y. And i have to run UPDATE STATISTICS under user y > > > id. Is it possible?? > > > > Create a 4GL or ESQL/C program that runs suid to a DBA account and have > > that app execute the UPDATE STATISTICS commands. You can get my > > dostats.ec from the IIUG Software Repository, in the submission named > > utils2_ak, and make it an suid program. > > Beware SUID programs with Informix. Historically, Informix only used the > real UID, not the effective UID which is set by a SUID program, for > controlling the database access -- and there was a good reason why it did > so which I'll go into if you really need me to. > > With shared libraries, running SUID programs gets tricky on many machines. > For example, on Solaris, the shared libraries must be accessible in > /usr/lib to be usable, or you have to link the program with special options > such as -R or with LD_RUN_PATH set in the environment. > > If you've worked around those issues, then you still have the problem that > Informix works with the real UID. You can specify a user and password when > you do an explicit CONNECT statement, and the database regards you as being > to the specified user regardless of your real or effective UID. This may > be your best approach -- write a program which will connect to the database > as a suitably privileged user with a compiled in password, but only do this > once the actual user has identified themselves by specifying an appropriate > password. You'll need to ensure that you don't let people get at the user > and password information casually, so your source code should not contain > either the special user's name or password in clear text -- they should be > encrypted (but reversibly) so that the not-so-casual scanner of the object > code won't spot the information. That's the bare minimum security; you > could get more paranoid than that, and keeping the source code off the > machine would be a good idea.