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

Is their a reason they need to be a member of the informix group, but not be informix? I guess that is my main question. Will >===== Original Message From Scott Black <sblack@elsouth.com> ===== >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 ------------------------------------------------------------ This e-mail has been sent to you courtesy of OperaMail, as a free service from Opera Software, makers of the award-winning Web Browser, Opera. Visit us at http://www.opera.com/ or our portal at: http://www.myopera.com/ Your free e-mail account is waiting at: http://www.operamail.com/ ------------------------------------------------------------

In article <8ho831$rb6$1@news.xmission.com>, William Rice <ricew@operamail.com> writes > >Is their a reason they need to be a member of the informix group, >but not be informix? I guess that is my main question. > >Will > User informix has one privilege that even root and the dba does not have (At least under SE). *** The ability to update systables *** We use this under SE to move tables. *** We know what we are doing, we know it is unsupported by *** *** Informix and we will fix it if we break it!! *** We normally create a separate DBA account who is in group informix. That way we cannot accidentally update system catalogues. -- David Williams