Re: Finding user

On Mar 27, 2:14 pm, "Goldrick, Jim" <jgoldr...@judsonu.edu> wrote: > This may have been gone over before, though I have found little about it > in my searches. If so, I apologize. > > We use a proprietary administrative system for our university. > Sometimes, when it calls an application from the menu, it changes the > real and effective user. I have a need to limit who can change work > records (used for both our employees and to track constituent employers) > for our employees. So I can't just limit the permissions of the table, > since it is also used for other constituents. I created a procedure > attached to a trigger to check who is doing the update. However, the > USER function returns the changed uid's login. > > I have tried creating a c udr that returns the effective uid, real uid, > or login attached to the tty. Nothing seems to return the actual user > who is logged in. > > So, I was wondering if anyone had any ideas on how I might find out who > is actually logged in even though the process is running under setuid? > Perhaps another c function somewhere that holds the original uid? This is tricky stuff that you are tampering with. The first problem is that a C UDR is run by IDS, not by the client. The server is run with root or informix as the effective UID; usually, the real UID is one of those two as well, unless you are running with role separation. Also, in general (though possibly not in your case), IDS is not even running on the same machine as the client. For complex historical reasons (think OnLine 5.x and earlier plus a SUID root, SGID informix sqlturbo program), Informix software assumes the real UID is the relevant one. (You should be able to find disquisitions from me and othes from the mid-90s on the subject in the archives - search terms 'setuid sqlturbo' work nicely.) Thus, a SUID program normally has its SUID-ness ignored; IDS gets told about the real UID and not the effective UID. The correct way to deal with this is to have the users connect to the database giving their username and password: EXEC SQL CONNECT TO "yourdb@yourserver" USER "whoever" USING :password; (You have to use a host variable for the password.) Of course, if this is not what your applications do, then you will have to change them, and people will have to be trained to identify themselves accurately. There are various troubling points in your description. The application sometimes changes the real and effective UID, you said. A non-SUID application that is run by an ordinary user cannot change either. A SUID application (e.g. SUID informix) run by 'anybody' can change the real or effective UID to either informix or anybody - but that's all. A SUID root application can change anything. Is your administrative application running SUID root? If you really wanted to get outrageously finnicky and your processes are all on a single machine and if you could reliably identify which process you were communicating with in this session (onstat -g ses?), then you could consider poking around the /proc/nnnn structure (where nnnn is the process ID of the client process) to see what you can identify. But you'd probably have to go backwards from the administrative application to the process that ran it (parent process ID) to identify people. This is sufficiently contorted and non- trivial that it most certainly is not a recommendation - and permissions will be a problem too, since access to the /proc information is limited. Ultimately, the user ID specified when you connect to IDS is what is used to track your activities inside IDS because there is no alternative information available. HTH - but I suspect it is not yet the answer you need. -=JL=-