Re: Unix Environment values from SPL/UDR

Arg, that would be a call to getuid() which returns the real user id. It would be a pretty trivial UDR, maybe 7 lines of code. Art On Mon, Oct 6, 2008 at 5:50 PM, Art Kagel <art.kagel@gmail.com> wrote: > WRite a UDR in "C" to call getreuid() and return the real user id. > > Art > > On Mon, Oct 6, 2008 at 5:15 PM, Rob Burba <inf4glguru@gmail.com> wrote: > >> OK, a challenge for all you gurus and highly intelligent Informix folks, >> yes that includes you Obnoxio!!! >> >> I have a system that has recently been "upgraded" to control access to the >> database through service accounts. Each user logs into the Unix system with >> their id and then runs the application using the sudo command to force the >> database engine to see them as the service account rather than an >> individual. This limit the overhead of security maintained at the >> individual user level. However, the desire remains to know the "real" user >> ID of all users who are adding/updating/deleting records. Previously, this >> worked fine just referencing the "user" variable in any select statement or >> as the return value from a stored proceedure. However, life is not so fun >> any more. >> >> Each user creates a record a database table tracking the session which >> associates a "real" user id with a TTY along with the department the user is >> using to access their data. Through a store procedure, the "real" user can >> be identified using DBINFO to get the session ID from the >> sysmaster:syssessions table and use the TTY to look up the user's database >> session record. From an interactive program perspective, this is minimal >> cost and not a problem. But this is where the problem gets dicey. >> >> Many of the tables in the database have triggers on the table to populate >> fields identifying the user who created the record and the user who last >> modified the record. These triggers call stored procedures to get the >> value. Previously the store procedures just returned "user" and that was >> correct. However, now the store procedures must perform the join described >> above. The result is a much slower system and folks sharpening their blades >> to cut off the heads of unsuspecting developers. >> >> My mission is to find a way for the stored procedures to get the "real" >> user id (the $LOGIN environment variable) since the "user" value returned by >> the engine is the service account name rather than the real user (because >> that is the current user id of the Unix session that connected to the >> database). Does anyone have any tricks or suggestions on how to get a >> stored procedure/UDR/Datablade or any other methodology other than 4gl to >> return the value of Unix environment variables? >> >> Help, please!!!!!! >> >> Technical info. Informix 10.00.FC8, AIX 5.3 >> >> Thanks!!! >> R >> >> _______________________________________________ >> Informix-list mailing list >> Informix-list@iiug.org >> http://www.iiug.org/mailman/listinfo/informix-list >> >> > > > -- > Art S. Kagel > Oninit (www.oninit.com) > IIUG Board of Directors (art@iiug.org) > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and do not reflect on my employer, Oninit, the IIUG, nor any other > organization with which I am associated either explicitly or implicitly. > Neither do those opinions reflect those of other individuals affiliated > with any entity with which I am affiliated nor those of the entities > themselves. > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.

Art Kagel wrote: > Arg, that would be a call to getuid() which returns the real user id. > It would be a pretty trivial UDR, maybe 7 lines of code. > > Art > > On Mon, Oct 6, 2008 at 5:50 PM, Art Kagel <art.kagel@gmail.com > <mailto:art.kagel@gmail.com>> wrote: > > WRite a UDR in "C" to call getreuid() and return the real user id. > > Art > > On Mon, Oct 6, 2008 at 5:15 PM, Rob Burba <inf4glguru@gmail.com > <mailto:inf4glguru@gmail.com>> wrote: > > OK, a challenge for all you gurus and highly intelligent > Informix folks, yes that includes you Obnoxio!!! > > I have a system that has recently been "upgraded" to control > access to the database through service accounts. Each user logs > into the Unix system with their id and then runs the application > using the sudo command to force the database engine to see them > as the service account rather than an individual. This limit > the overhead of security maintained at the individual user > level. However, the desire remains to know the "real" user ID > of all users who are adding/updating/deleting records. > Previously, this worked fine just referencing the "user" > variable in any select statement or as the return value from a > stored proceedure. However, life is not so fun any more. > > Each user creates a record a database table tracking the session > which associates a "real" user id with a TTY along with the > department the user is using to access their data. Through a > store procedure, the "real" user can be identified using DBINFO > to get the session ID from the sysmaster:syssessions table and > use the TTY to look up the user's database session record. From > an interactive program perspective, this is minimal cost and not > a problem. But this is where the problem gets dicey. > > Many of the tables in the database have triggers on the table to > populate fields identifying the user who created the record and > the user who last modified the record. These triggers call > stored procedures to get the value. Previously the store > procedures just returned "user" and that was correct. However, > now the store procedures must perform the join described above. > The result is a much slower system and folks sharpening their > blades to cut off the heads of unsuspecting developers. > > My mission is to find a way for the stored procedures to get the > "real" user id (the $LOGIN environment variable) since the > "user" value returned by the engine is the service account name > rather than the real user (because that is the current user id > of the Unix session that connected to the database). Does > anyone have any tricks or suggestions on how to get a stored > procedure/UDR/Datablade or any other methodology other than 4gl > to return the value of Unix environment variables? > > Help, please!!!!!! > > Technical info. Informix 10.00.FC8, AIX 5.3 > > Thanks!!! > R > > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org <mailto:Informix-list@iiug.org> > http://www.iiug.org/mailman/listinfo/informix-list > > > > > -- > Art S. Kagel > Oninit (www.oninit.com <http://www.oninit.com>) > IIUG Board of Directors (art@iiug.org <mailto:art@iiug.org>) > > Disclaimer: Please keep in mind that my own opinions are my own > opinions and do not reflect on my employer, Oninit, the IIUG, nor > any other organization with which I am associated either explicitly > or implicitly. Neither do those opinions reflect those of other > individuals affiliated with any entity with which I am affiliated > nor those of the entities themselves. > > > > > -- > Art S. Kagel > Oninit (www.oninit.com <http://www.oninit.com>) > IIUG Board of Directors (art@iiug.org <mailto:art@iiug.org>) > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and do not reflect on my employer, Oninit, the IIUG, nor any other > organization with which I am associated either explicitly or implicitly. > Neither do those opinions reflect those of other individuals affiliated > with any entity with which I am affiliated nor those of the entities > themselves. > I'd say the answers are mixing the server and the client environment... The OP needs something from the client environment... And the solutions would get something from the server environment... Regards -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...