Re: Subject: Re: OT: Don't create tables owned by informix -

Write a C program that runs onstat -g ses argv<1> that takes one parameter, makes sure it is up to 8 character long and it is all digits.....easy! Also a seperate replacement for onstat -g sql that does the same validation. Love Dave. PS Was thinking about this today. How far wrong can you go running onstat -g ses <argv[1]> when you make sure argc indicates one argument, argv is not too long and is only digits?

david@smooth1.co.uk wrote: > Write a C program that runs > > onstat -g ses argv<1>> > that takes one parameter, makes sure it is up to 8 character long and > it is all digits.....easy! > > Also a seperate replacement for onstat -g sql that does the same > validation. > > PS Was thinking about this today. > > How far wrong can you go running > > onstat -g ses <argv[1]>> > when you make sure argc indicates one argument, argv is not too long > and is only digits? So, your proposed C program is a setuid program? Setuid to root, or informix, or something else? How, exactly, are you planning to run 'onstat' securely? (Hint: $INFORMIXDIR is an environment variable; I can set it to what the hell I like. How are you going to run 'onstat' securely again? If the answer wasn't "as /opt/informix/bin/onstat" - where /opt/informix is the name of your INFORMIXDIR - then you have no business writing the program. If you knew about using the absolute path name, how many ways can you still be broken? Which function do you use to execute it? Why? If you don't know that, you probably shouldn't be writing the program.) Don't do it until you've looked at what 'sudo' deals with: LD_PRELOAD, IFS, etc. (http://www.courtesan.com/sudo/). Don't do it until you've looked at what Matt Bishop has to say: http://nob.cs.ucdavis.edu/~bishop/secprog/ (Specially ns1997.pdf - short - and sans2002.pdf - long!) Don't do it until you've looked at what David Wheeler has to say: http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/ And, as I commented earlier, allowing arbitrary users to see anyone else's SQL (via 'onstat -g ses') is apt to compromise social security numbers, phone numbers, salaries, passwords, credit card numbers, account numbers, and other such information. What controls are you planning to restrict who can look at whose sessions? If you don't care about that sort of security, it is simpler and more reliable to just configure UNSECURE_ONSTAT 1 in the $ONCONFIG file. If you still think it might be an idea to write the program, look at whether sudo can be used instead. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/