Re: different version different owner for IDS
Oh dear - how hard the easy questions can become... Yesterday, I started
to answer Chris Priest's question below as follows.
You should probably read chapter 2 of the Trusted Facility Manual.
There it talks about DBSA (database system administrator), DBSSO( database
system security officer), and AAO (audit analysis officer) -- as well as
DBA and OSA (operating system administrator). DBSAs are members of the
group that owns $INFORMIXDIR/etc; DBSSOs are members of the group that owns
$INFORMIXDIR/dbssodir, and AAOs are members of the group that owns
$INFORMIXDIR/aaodir. In theory, at any rate, you can have different people
administering different servers if:
1. You continue to install everything as root/informix.
2. You set the group that owns $INFORMIXDIR/etc to different groups in each
instance (eg ix32, ix64).
3. You grant the people who need to administer the 32-bit instance
membership of the ix32 group (and not the ix64 group) and so on.
Note that, within some minor limits, the uberuser (informix) can do
anything to any of these instances -- I think. So, you'd still need to
keep very careful tabs on user informix (and group informix, and user
root). But the members of the various DBSA groups should be able to manage
the systems they are privileged to control.
[As I wrote y'day] What I've not done is experiment with this - nor do I
know of anyone who has (though neither have I asked around about this). I
assume that the device permissions still need to be 660 informix:informix,
and that most of the material in $INFORMIXDIR needs to be root owned or
informix owned -- though there are plenty of areas where the actual owner
really doesn't matter very much (such as the message files). The files in
the AAO directory and DBSSO directory need appropriate privileges - a
wonderful weaselly term from the POSIX standards (where there is no
super-user per se - you just appropriate privileges to do various
operations traditionally restricted to root on orthodox Unix systems). The
files in $INFORMIXDIR/etc/*files tell you what the privileges are supposed
to be, assuming you know the mapping for the AAO and DBSSO (and DBSA)
groups. Don't forget 'bargroup' if you are using ON-Bar. And, as always,
you must keep extremely careful control over user root and user/group
informix.
I was just finishing up my homework when I followed my own advice, and read
the chapter - at least, I scanned it to check the information I was
relaying. On p2-9 (in the 9.2, 9.3 and 9.4 versions of the documentation),
it says:
Users who can perform the DBSA role are group members of the group that
owns the directory $INFORMIXDIR/etc.
Users who can perform the DBSSO role are group members of the group that
owns the directory $INFORMIXDIR/dbssodir.
Users who can perform the AAO role are group members of the group that
owns the directory $INFORMIXDIR/aaodir.
So far, so good. Well, actually, not really. That was only after I
recovered from a heart attack because the first page I found was 2-4, where
it says:
Tip: A DBSA is any user who belongs to the group informix (Unix) or logs
in as user infomrix (Windows), with or without role separation.
Unfortunately, these two statements are not compatible with each other
unless the group to which $INFORMIXDIR/etc belongs is group informix. So,
one of them is erroneous in the general (but unusual) case where group
informix does not own $INFORMIXDIR/etc.
Hah, you say - which one? Good question - yesterday, I didn't know.
Today, after experimentation, I find that p2-9 is correct and p2-4 is
incorrect.
The DBSA privileges are granted to people who belong to the group that
owns the $INFORMIXDIR/etc directory.
There are a few additional wrinkles to worry about:-
1. The permissions on oninit must be modified to 6755 (granting others
execute permission) if the new DBSA is to start the server.
2. The permissions on $ONCONFIG do not seem to be critical, but for a
DBSA to be able to modify it, it makes sense for the file to belong to the
DBSA group.
3. ON-Monitor does not recognize the DBSA group - if you aren't informix
(not even root) then you can only do profiling operations with ON-Monitor.
4. ON-Check does not allow the DBSA group to things that you 'must be
user informix to run' (eg 'oncheck -pk dbname').
5. Using ON-Spaces requires cooperation from the OSA (operating system
administrator - aka root) since DBSA probably can't set the user and group
permissions on devices or files.
6. It is not clear whether a DBSA has privileges to start ER (using the
cdr command). Nor is it immediately obvious is controlling ER is a DBSA or
DBA task - or someone else's job.
7. It is not clear why all users can run ON-Log.
8. ON-Tape recognizes DBSA.
9. Some options in onstat (eg onstat -g src 0x2E 0xFF) require
'informix' privileges rather than DBSA privileges.
It's a novelty to be able administer my server without having to use my
SUID root program to do things. It happens to be 9.40.UC1 on Solaris 8;
but I don't think this is an area that has been modified significantly.
I've reported this to the Informix Tech Pubs email alias - and I'm copying
them on this response too. Note the extra points (3 and up) in the
numbered list just above!
--
Jonathan Leffler (jleffler@us.ibm.com)
STSM, Informix Database Engineering, IBM Data Management
4100 Bohannon Drive, Menlo Park, CA 94025
Tel: +1 650-926-6921 Tie-Line: 630-6921
"I don't suffer from insanity; I enjoy every minute of it!"
|---------+---------------------------->
| | "Murray Wood...."|
| | <ifxmaillist@quan|
| | ta.co.nz> |
| | Sent by: |
| | forum.subscriber@|
| | iiug.org |
| | |
| | |
| | 06/30/2003 02:02 |
| | PM |
| | |
|---------+---------------------------->
>-------------------------------------------------------------------------------
--------------------------------------------------------------|
| |
| To: ids@iiug.org |
| cc: |
| Subject: RE: different version different owner for IDS [1460] |
| |
>-------------------------------------------------------------------------------
--------------------------------------------------------------|
Chris
Dont know why your administrator would want to run as different users.
This
just sets up more userid's that add to the security risk.
You can set different user-ids that belong to group informix and these can
start the engine. You still need user informix and group informix ... plus
all the other users he wants.
MW
> -----Original Message-----
> From: forum.subscriber@iiug.org [mailto:forum.subscriber@iiug.org]On
> Behalf Of CHRIS PRIEST
> Sent: Monday, 30 June 2003 5:14 p.m.
> To: ids@iiug.org
> Subject: different version different owner for IDS [1453]
>
> I regularly setup our machines to run multiple versions
> of IDS on the same machine and I always have it by the book
> as owner informix and group informix. Recently I was asked by
> a security administrator was it possible to have separate
> instances owned by different accounts? For example the 32bit
> instance would be informix32 and the 64 bit instance would be
> informix64. My reading to date suggests nothing has