USER in informix

I have written a perl program to connect to an external box. The DBI->connect requires user name and password. In order to avoid hardcoding password in the perl text file I followed this approach:- $password=`PrintPassword` chop($password); PrintPassword is an ESQL/C program which simply printf the password. (of course I have taken care to ensure that strings PrintPassword does not reveal the password). Since the password is to be supplied to only one user I am checking like this:- $ select count into :wcount from systables where USER = 'abc' ; This works like a charm. Unless I log on as 'abc', the program does not print the password. However I want to confirm how does Informix check USER. AFAIK it goes by real user id and not effective user id. That is the takes the user name by which someone logons to the box or connects to the database. Is there a hole in my assumption? TIA. Ravi

rkusenet wrote: > I have written a perl program to connect to an external box. The > DBI->connect requires user name and password. Actually, DBD::Informix doesn't - you can leave them blank or undefined and the default connection with no name will occur. $dbh = DBI->connect("dbi:Informix:$mydbname",'','',{RaiseError=>1}); > In order to avoid hardcoding password in > the perl text file I followed this approach:- Good idea not to embed the password... > $password=`PrintPassword` > chop($password); > > PrintPassword is an ESQL/C program which simply printf the password. ESQL/C? Why does it access the database? More significantly, how does it access the database? Most likely in a way equivalent to the DBI->connect statement above. > (of course I have taken care to ensure that strings PrintPassword does > not reveal the password). Since the password is to be supplied to only > one user I am checking like this:- > > $ select count into :wcount > from systables > where USER = 'abc' ; So, this is the ESQL/C program at work? And you are checking whether the user who connected has the fixed name - you only care about the difference between zero and more than zero. So, I think my first paragraph deals with your problem. > This works like a charm. Unless I log on as 'abc', the program does not > print the password. However I want to confirm how does Informix > check USER. It depends. > AFAIK it goes by real user id and not effective user id. For the default case (where you do not specify user name and password at connect time), that is correct. The reason is historical; in the days of OnLine and SE (meaning today, still), the server is forked and executes a SUID root, SGID informix program. When you do that, the server's EUID and EGID are known (root, informix) and any non-default EUID or EGID from running a SUID/SGID application are lost. (The RGID and EGID have very little effect on things; I mention them for completeness rather than significance.) Hence, those servers can *only* ever use the RUID and RGID. With IDS (6.00 and above, including XPS - which have been known by many names over the years), it would be feasible to work with the EUID of the application, but for consistency with prior art (OnLine, SE), it still uses the RUID. When you specify the username and password in the CONNECT statement, then the [RE][UG]ID are immaterial. > That is the takes the user name by which someone logons to the box > or connects to the database. Is there a hole in my assumption? No; not necessarily the name by which they login - but certainly that's the normal case. Consider someone who runs 'su'; it is the 'su' ID (typically, but not necessarily, root) that is used, not the ID used to login originally. it depends on the RUID of the program at the time when the CONNECT statement (or DATABASE statement) is executed. A SUID root program can, therefore, become anybody it wishes for the purposes of connecting to the database. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

Jonathan Leffler wrote: > Actually, DBD::Informix doesn't - you can leave them blank or undefined > and the default connection with no name will occur. AFAIK, only for connections from trusted box. In my case, not only is the local box untrusted, the user name is also different on the remote box. So the only way is to explicity supply username/password. >> PrintPassword is an ESQL/C program which simply printf the password. > > > ESQL/C? Why does it access the database? More significantly, how does > it access the database? Most likely in a way equivalent to the > DBI->connect statement above. I should have been clear. ESQL/C access local database (where Perl is running), not the remote one the Perl program wants to connect. > So, this is the ESQL/C program at work? And you are checking whether > the user who connected has the fixed name - you only care about the > difference between zero and more than zero. So, I think my first > paragraph deals with your problem. The ESQL/C program just authenticates whether the user who is calling the program is indeed the one who has logged on to unix as that user. I know this can be achived by a simple C program but I am more comfortable in checking it via USER clause. Hence ESQL/C. > For the default case (where you do not specify user name and password at > connect time), that is correct. The reason is historical; in the days > of OnLine and SE (meaning today, still), the server is forked and > executes a SUID root, SGID informix program. When you do that, the > server's EUID and EGID are known (root, informix) and any non-default > EUID or EGID from running a SUID/SGID application are lost. (The RGID > and EGID have very little effect on things; I mention them for > completeness rather than significance.) Hence, those servers can *only* > ever use the RUID and RGID. With IDS (6.00 and above, including XPS - > which have been known by many names over the years), it would be > feasible to work with the EUID of the application, but for consistency > with prior art (OnLine, SE), it still uses the RUID. This is what I expected and this is what I want. So I am assured that to print the password, the user must log on to the box as that specific user only. > No; not necessarily the name by which they login - but certainly that's > the normal case. Consider someone who runs 'su'; it is the 'su' ID > (typically, but not necessarily, root) that is used, not the ID used to > login originally. it depends on the RUID of the program at the time > when the CONNECT statement (or DATABASE statement) is executed. A SUID > root program can, therefore, become anybody it wishes for the purposes > of connecting to the database. CONNECT does not apply in this case. su I don't worry much since only root can su as my user. thanks all. ravi

rkusenet wrote: > Jonathan Leffler wrote: I think you're mainly in the clear - but I'm not convinced it is all that advisable as a strategy. See the notes below; there's a summary at the bottom that reiterates my concerns, but says "You're probably more or less OK" too. >> Actually, DBD::Informix doesn't - you can leave them blank or >> undefined and the default connection with no name will occur. > > AFAIK, only for connections from trusted box. In my case, not only > is the local box untrusted, the user name is also different on the remote > box. So the only way is to explicity supply username/password. Yes; you're right about trusted access. >>> PrintPassword is an ESQL/C program which simply printf the password. >> >> ESQL/C? Why does it access the database? More significantly, how >> does it access the database? Most likely in a way equivalent to the >> DBI->connect statement above. > > I should have been clear. ESQL/C access local database (where Perl is > running), not the remote one the Perl program wants to connect. OK - and you trust this untrustworthy client machine? >> So, this is the ESQL/C program at work? And you are checking whether >> the user who connected has the fixed name - you only care about the >> difference between zero and more than zero. So, I think my first >> paragraph deals with your problem. > > The ESQL/C program just authenticates whether the user who is calling > the program is indeed the one who has logged on to unix as that user. > I know this can be achived by a simple C program but I am more comfortable > in checking it via USER clause. Hence ESQL/C. OK - and anybody who ever looks at your script can determine the program that echoes the password and then use it for themselves? It saves the user typing, but I'm not sure it achieves the security you are after. >> [...] With IDS [...], [...] for >> consistency with prior art (OnLine, SE), it still uses the RUID. > > This is what I expected and this is what I want. So I am assured that > to print the password, the user must log on to the box as that specific > user only. It depends on the extent to which you trust your client box - as hinted above. If you trust that the users on that box can't become root, then yes. If not, all bets are off. >> No; not necessarily the name by which they login - but certainly >> that's the normal case. Consider someone who runs 'su'; it is the >> 'su' ID (typically, but not necessarily, root) that is used, not the >> ID used to login originally. It depends on the RUID of the program at >> the time when the CONNECT statement (or DATABASE statement) is >> executed. A SUID root program can, therefore, become anybody it >> wishes for the purposes of connecting to the database. > > CONNECT does not apply in this case. su I don't worry much since only root > can su as my user. It depends on which case you think CONNECT does not apply to. If you are referring to your program, you are most likely correct. If you are referring to DBD::Informix, you are almost certainly incorrect (you are incorrect unless you happen to be using ESQL/C 5.x - whereupon the username and password are always ignored by DBD::Informix). Because you're using a modified 'su' program that only root can run? Anybody who knows your user's password can normally 'su' to that user. As before, it call comes down to trust - how much do you trust the users on the local machine? After all that, you're actually basically in the clear. I'm not sure that it is all that advisable as a technique - anybody who walks up to the terminal while the user is at lunch can automatically connect to the remote database - but it should work within its limitations. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

Jonathan Leffler wrote: >> I should have been clear. ESQL/C access local database (where Perl is >> running), not the remote one the Perl program wants to connect. > OK - and you trust this untrustworthy client machine? Didn't get it. Can you explain it. > OK - and anybody who ever looks at your script can determine the program > that echoes the password and then use it for themselves? > It saves the user typing, but I'm not sure it achieves the security you > are after. This is serious and I hope you are wrong. I believe it is impossible. Anyone who is going to run the program, other than one designated user, will not have the password echoed back. Never. That was the whole idea of this echo_password program. I will take this offline. Thanks for your suggestion. Ravi