Re: USER in informix

rkusenet wrote: > 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. You have a database running on the client machine. You don't trust the client machine, which is fair enough. But you do trust that the instance of the database running on the client machine has not been subverted? Do the users of this client machine have root access to it? If so, then the database is not secure. If not, you're in with a chance that the client is secure enough (distinctly different from secure). You program is trusting that the client has not been subverted too badly - we had a discussion offline about the source code and the different ways it could be abused. >> 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. Scripting languages require that the scripts be readable and executable by the person running them. Consequently, anybody who can run the script can read it. That, in turn, means that anybody can find out which program is used to supply the password. > 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. Well, once you tighten up the code you showed me, you can get moderately close to secure. However, if there's a debugger on the machine, anyone can step through the code, and probably see what is being done by the program. A better technique would be to have the program owned by the user - dba - for whom it is supposed to work, and to have the permissions set to 500 or 100 (read/execute, or execute only, for the owner). As long as no-one unauthorized can modify the contents of the directory where the program is installed - nor place their own version of the program ahead of that in the PATH (you were going to use an absolute pathname, weren't you) - then you have a simpler system for detecting the user, without having to rely on the database for security. Of course, if someone who you don't trust has root access to the machine, then all bets are still off. Note, incidentally, that the 'cannot modify the directory contents' rule applies recursively up to the root directory. If an unauthorized user can move any of the directories out of the way, then it is possible to fake pretty much anything they want. > I will take this offline. Thanks for your suggestion. > > Ravi -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/