Re: Onstat -g ses only for DBSA?

mosserp@wellsfargo.com wrote: >>From: Art S. Kagel >>Sent: Thursday, April 07, 2005 4:10 PM >> >>Lucho wrote: >>>There are two servers. >>> >>> One of them with an informix server version: IBM Informix Dynamic >>> Server Version 9.30.UC6W4 and the other IBM Informix Dynamic >>> Server Version 9.40.FC5 >>> >>> When I execute the command Onstat -g ses on the first one >>> (version 9.30), it's all good but when I execute the command on >>> the second one (version 9.40), I've got the following error: >>>Must be a DBSA to run this program. >>> >>>I am not DBSA in any of these servers. >>> >>>What's the problem? THANKS! >> >> It's a new feature in online 9.40 & 10.00 to meet security >> requirements they decided some commandline tools are for Server >> administrators (DBSA) only. Get the DBSAs to define you with DBSA >> priveleges and voila! > > > And just how do you do that?? I did a search in the manuals (Admin > Guide, Admin Ref, Perf Guide) for "DBSA" and came up with nothing. The DBSA term is defined in the Trusted Facility Manual, along with OSA for operating system administrator, DBSSO for database system security officer and AAO for audit analysis officer. Fundamentally, the DBSA manages the server, the DBSSO determines what gets audited, the AAO determines whether anything is actually audited and analyzes the audit logs - and the OSA keeps the rest of the system running smoothly. In more detail, the DBSA group (note group - not user) is the group that owns $INFORMIXDIR/etc; the AAO group is the group that owns $INFORMIXDIR/aaodir; and the DBSSO group is the group that owns $INFORMIXDIR/dbssodir. By default, group informix wears all three hats. And, in sensibly configured systems, only user informix belongs to group informix, so user informix is the DBSA, DBSSO and AAO all at the same time. However, under role separation, you can distinguish between the three separate tasks, and allocate different groups to do each. > Actually, I think that this is a great idea for a *production* > environment, but our developers are complaining about not being able > to see the 'onstat -g ses' info on their dev/test boxes, and I think > that their complaints are valid. See my comment y'day that maybe IDS should have provided a configurable override for this. But, that configurable override would have to be usable only by the DBSA - though it is an interesting question whether that's truly the best choice (should it be the DBSSO?). Perhaps more importantly, it would certainly be the case that Joe Random Developer and friends could not assign the privilege to themselves by simply setting an environment variable, for instance. > I hope that the answer is *NOT* to give them sudo to 'informix' -- I > really don't want to go that far. No - that would be a blunderbus approach - if not also a blunder. If you have to let them use sudo, you use sudo to some other user or group than informix, and then give that restricted group to a tool that permits them to run precisely the programs you want them to run and no more. You do have to be extremely careful - the obvious approach uses a SUID root program (a less obvious approach uses a SUID informix program), but writing those is not for the faint of heart. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2005.01 -- http://dbi.perl.org/