Re: Subject: Re: OT: Don't create tables owned by informix -
- From: Jonathan Leffler <jleffler.iiug@xxxxxxxxx>
- Date: Wed, 2 Nov 2005 21:28:51 -0800
On 11/2/05, Dave Thacker <dthacker@xxxxxxxxxxxxxxxxx> wrote:
>
> On Thu, 2005-10-27 at 11:51 -0700, Jonathan Leffler wrote:
> > On 10/26/05, Dave Thacker <dthacker@xxxxxxxxxxxxxxxxx> wrote:
> > IDS 9.4FC6 on AIX 5.3. ISQL 7.32FC2
> >
> > [...]
> >
> > Schemas:
> > create table "informix".bar
> > (
> > [...]
> > );
> >
> > create table "informix".foo
> > (
> > [...]
> > );
> >
> >
> > It's probably unfair to pick on Dave, but he's (unwittingly) offered
> > me the opportunity to make the comment:
>
> It may be my only purpose is to serve as a warning to others....;)
>
> > As a general rule, user informix should neither own 'operational'
> > databases nor any user tables (as distinct from the system catalog
> > tables) in the database. It makes it impossible to separate the
> > multitude of roles that user informix already has (DBSA, DBSSO, AAO -
> > and this adds the DBA role). You should create a separate user ID to
> > own and administer the database.
>
> This *is* in the works.
>
> > There are going to be times when this is impossible - and Dave may be
> > in such a bind. For example, the company may baulk at creating any
> > new user ID - and were probably unhappy when user informix was added.
> > However, even then, you might have to create the database as informix
> > (though why not as yourself), but all the tables could be owned by a
> > non-existent user ID.
>
> I chalk this up to what I call "small shop" mentality. There aren't many
> of us, and we're all trustworthy, right? Fortunately, my boss has seen
> your "Paranoid DBA" presentation, and that has opened the door a bit. I
> highly recommend this presentation to c.d.i readers that have not seen
> it. We're behind on implementing some of Jonathan's recommendations, but
> they will be implemented soon.
Yes; separation of roles is a thing that bigger shops pay more attention to.
In a small shop, the same small group of people end up with all roles, so
using a single user for all of them looks nice and easy. It just isn't best
operating practice - especially w.r.t database ownership. Conflating DBSA,
DBSSO and AAO (or, more usually, ignoring DBSSO and AAO) is often sensible.
Mixing this group with DBA is not so sensible.
Since I've been made an example of, I'll take this opportunity to ask
> you, Jonathan. What you think of the use of the sudo utility to grant
> developers access to onstat commands for the purpose of monitoring
> performance on their applications. Safe? Unsafe? Alternatives?
>
Using sudo is a sensible and reasonable mechanism - and it is largely safe.
The only reason for the caveat is a concern about whether sudo can limit the
valid options - and whether you would want to do that. (Note that
1.6.8p11was released on 28th October 2005 - keep up to date with it!).
Judging from
the man page at http://www.courtesan.com/sudo/man/sudoers.html, you could
specify the options that you're willing to let your developers use - the
staggering part with onstat is the sheer number of such options that exist.
--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@xxxxxxxxxxxxx, jleffler@xxxxxxxxxx
Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/
sending to informix-list
.
- Follow-Ups:
- Prev by Date: Not sure whats happening to update statistics
- Next by Date: Re: Not sure whats happening to update statistics
- Previous by thread: Not sure whats happening to update statistics
- Next by thread: Re: Subject: Re: OT: Don't create tables owned by informix -
- Index(es):
Relevant Pages
|
