RE: onstat: Shared memory: permission denied???

At this point I think I should explain I don't give this group to everyone. It only goes to MIS personnel. And it only happens when they have been here sufficiently long to indicate that they know what they are doing (at the same time they get the root password(s), and 'grant DBA to [...]') From the responses that I have gotten, there doesn't seem to be any reason that Informix itself doesn't like this (database integrity issues) it is a simply matter of trust of the skill level of the people within the group. If you have a large shop and some people are rookies, then by all means don't put them in the Informix group. On the other hand, don't blindly go around chanting: "Never use group Informix" as seems to be the mantra that you see in this forum. Using the group Informix can be of some slight advantage, and there isn't necessarily any SOFTWARE reason not to, only security reasons. ...Next week I'll bring up the question: "Why not create every database/table/index/procedure/trigger as user informix?" -----Original Message----- From: Joshua R. Poulson [mailto:Josh.Poulson@informix.com] Sent: Wednesday, June 07, 2000 2:19 PM To: Scott Black Subject: Re: onstat: Shared memory: permission denied??? Scott Black wrote: > I've heard this for the past few years on this list, and I have yet to > find a reason why. We do it, and have NEVER had ANY problems > whatsoever. There is however a slight advantage in having a readymade > group that MIS can use. Whatever the security reasons are, they are > still there. If I were unable to do something due to not being in group > Informix, I would just su to root (or informix) and do it anyway. This > way is less typing. > Why all the paranoia? Paranoia is an unwarranted fear. A warranted fear is just caution. The more classes of users you give the ability to examine the shared memory of the server, run the onmode commands, or other actions that are normally reserved to the DBA, the higher the chance of an attacker (either external, or a disgruntled or dishonest employee) will be able to perform the three things the can cause the most damage to your database: 1) They can learn information that they should not know, violate privacy or secrecy policies, and so on. 2) They can destroy the information causing you to have to reload from backup and possibly lose the day's transactions. or, the worst case 3) They can change the information, perhaps undetectably. The fundamental principle of security is to give users the appropriate level of access for their role with respect to your business process. DBAs, by their nature, need extraordinary levels of access to the database they maintain and administer. However, it is generally a bad idea to allow DBA levels of access to accounts that do not need it. You may think that restricting the users that can log onto your machine protects you from unwanted incursions, but the more users on a machine, the more likely that someone can get lucky with an attack. So, as a corollary to the "role" principle, there is the principle that limiting the interfaces with extreme levels of access can also benefit your security. One aspect of this is limiting the number of accounts with such extraordinary access. --jrp