Very Computer

Request for open discussion:

There has been a battle going on around here on administrating
some of the system flat files associated with Unix. The file of concern
are /etc/passwd, /etc/group, /etc/hosts, and some configuration files
used by a menuing system. On one side is the system administration staff
and on the other is the Oracle dba staff and other Oracle developers.
The Oracle people want their database to contain the "seat of truth"
when it comes to Unix system files. They want Oracle applications written
(some are in development as I write this) that will accept input of what
would normally be put directly into the flat files mentioned above. Then,
Oracle would execute a SUID program with PRO-C calls to extract the
information from from its tables and modify the system files. System
administration is fighting to have this approach stopped and wonder why
there is even a hassle about it.

Database people contend:
   The master of all data (even system) is Oracle. This data is needed
   for a variety of things and, because of company policy, if it is in the
   database that should be the master copy. More check can be made on
   the integrity of the data and that means a more dependable system.
Sys admin responds:
   Fine, if you want system data, the files are readable. But, Oracle
   does not control the system; Oracle run on top of Unix
   If it takes root access, it's our responsibility so don't worry about it
   We don't want any Oracle programs controlling system files for the
   following reasons:
   a. Support issues (system administration doesn't know Oracle).
   b. We want to build and modify our own admin tools.
   c. There is a question of security. Database people need root access
      to write these applications. Also, anyone could put a command in
      to provide a suid shell.
   d. If something break, who get called? System administration.

Has anyone run into this argument before? Can someone explain to me
why there is even an issue here? I admit to being a system administrator
but tried to relate what is happening with as little bias as possible.

                                Thank you all,
                                Gary Barnette
                                uunet!uswnvg!gbarnet

  I have been tempted to implement something similar to what your Oracle
  people propose, for several reasons:

    1. better "data management" of system files.  We have people logging in
       to multiple cpus, for reasons I won't go into we do not run YP or
       Kereboros, we add/delete/modify 10-20 users per week, and system ad-
       ministration is a major pain and often "inaccurate".  This in itself
       is not enough to recruit the use of a large, unwieldy dbms, since tools
       can (and have been) developed, but for subsequent reasons;

    2. the dbms itself, that we run in client-server configurations (e.g.,
       multiple clients and multiple servers), also has user information data
       that has to be maintained.  Much of it overlaps (from the point of view
       of what one has to enter) the system files;

    3. most individuals are put directly into menus as soon as they log in.
       These menus are implemented in and are tied to the dbms and the appli-
       cations we have developed.  Which menus a given user sees and what data
       the user has access to is determined by information in the databases,
       some of it via formal dbms permits the rest of it by our own tables.
       This data too overlaps the data in the system files.

  So what we end up with is data redundancy (system- and dbms- related) and
  the usual problems this causes, such as inconsistencies.  It is very temp-
  ting, then, to contemplate using the dbms as the recipient and repository
  of a "master" user database from which we could generate passwd, group, and
  other files on demand.

  I would not permit the use of SUID'd scripts.  But this is not a restric-
  tion in itself.  It's been a long time since I had the "pleasure" of using
  Oracle, so I don't know whether the following is possible:  in our case,
  if we proceed with this, the user database will be "owned" by root but with
  updating privileges granted to other appropriate users.  So "root" will
  determine who those "appropriate" users are and will also control who will
  have access to which parts of the database.  Routines to generate
  and install system files will have to be executed by the few who have "root"
  access.  Or, put it this way: it may well be that others will be able to
  create the output, but a "root" will have to install it.

  I realize that we are not a "typical" site in that our environment is tilted
  very heavily towards dbms-based applications which, furthermore, are rather
  homogeneous.  This factor has pushed us in a certain direction which may or
  may not have relevance to your environment.

Have the Oracle-heads considered how they are going to handle passwords?
What happens if a user changes his/her password using 'passwd' (whether
or not they are "supposed" to).?  Will the new password be incorporated
into ORACLE?  Or will a change in ORACLE exported shortly after the user
has made a change overwrite the change when overwriting the file?  What
if password aging is in effect and forces the user to change passwords
using 'passwd'?

Passwords control is >>far from the only<< issue but is sufficiently
illustrative to show the dangers of the "ORACLE IS TRUTH" approach.

Bet IBM doesn't keep VM passwords in DB2 (or do they?)!
--
Bill Meahan                     |Product Design & Testing Section
Production Test Engineer        |Starter Motor Engineering

1) How are you going deal with the other programs that are used to maintain those files? passwd, chfn, chsh, and any of the other programs that use the standard system calls, with the appropriate privileges, allow general users to modify their information in those files. These commands must be eliminated or modified to comply with your 'NEW STANDARD'.

Is your programming staff ready to take on OS support and development responsibilities for all of the OS varients that Oracle runs on? Will it work with the BSD password hashing routines, the Unicos passwd file shadowing routines, the UTS /etc/identity file, etc.?

2 ) Using a database to maintain those files is a "good thing". Adding the requirement that a commercial package that I must install on my system will manage those files is a "bad thing". I would probably veto the procurement of a commercial database package for general use if I discovered that it came with hooks to modify system files...

---
My suggestions would be a tool that monitors those files, and reports pertinent discrepancies to the administrators, or a set of general tools for mantaining those files, that could be tested, modified, and accepted by the local system administrators on a case-by-case basis.
---

To clarify my biases <grin>

We have a locally developed account management system that maintains the passwd and group files on over 200 systems. It runs unders a commercial database package on one system and can update the system files on all of the client systems. We also have a separate software package that audits the files on all of the systems, monitoring for changes. However, the information in the passwd and GECOS fields tend to drift over time as the users manually update them on individual systems. We do not try to control t

hat drift...

Host tables are control by a different mechanism, based on nameservice.
--

NASA Ames Research Center       (415) 604-4366
---
Perception is reality...

     So what we end up with is data redundancy (system- and dbms- related) and
     the usual problems this causes, such as inconsistencies.  It is very temp-
     ting, then, to contemplate using the dbms as the recipient and repository
     of a "master" user database from which we could generate passwd, group,
     and other files on demand.

I think this is backwards. It requires training everyone who wants to
change the data in the password/etc files to use a new set of tools,
and probably learn a new way of dealing with them.

By doing it the other way - regenerating the database each time the
system files are changed - you allow people to continue using their
old tools. Any programs that read the file can be left unchanged.
Programs that _write_ the file need to be tweaked. The worst case is a
shell wrapper that runs the real writer program, then runs a program
to rebuild the database from the password file, with appropriate
locking on the database to keep things in synch. This allows you to
continue using current admin tools with no change, and keeps the
database in sync (barring accidents) with the password file.

Doing it the other way means that the class of accidents that break
the database would break all the programs that depend on
/etc/password, unless you've changed them to use the database (not a
bad idea if they're doing liner searches).

        <mike

--
When logic and proportion have fallen softly dead,      Mike Meyer

And the red queen's off her head,                       decwrl!mwm
Remember what the dormouse said.

Oracle is not part of the O/S.  It's an add-on.  How well
would Oracle work in single user mode with only the root file system mounted?
What is there to enforce Oracle (or any DB system) as the data 'God'?

Why would you want to add layers of complexity to a relatively simple task?

Have the Database people ever heard of the K.I.S.S. methodology?  (Keep It
Simple Stupid)  Hmm, "simple", "Database",.....oxymoron.  Silly question.

The database people are "Users".  Period.

The system administrators are the "System Administrators".  Period.

The system administrators are responsible for the systems.  How well would the
excuse, "Well, you see, the data base is corrupted and we can't recover..."
go over?   That's what I thought.

It sounds to me like the Oracle people need more work to do, and are trying
to generate some for silly reasons.  You as system administrator may use
or develop any tools you like.  It is also YOUR A*S on the line.

I would tell the users to do their own job and let me do mine.  I would
be very hesitant to surrender control of critical functions to a User written
application (Unless I wrote it, of course. :-)).  (You just can't TRUST a
user...:-))

(If that hasn't set me up as the main course for a "Users feeding frenzy", then
 I don't know what would.... Do users read the net? :-))

craig

Let me start by saying that I basically feel like everyone else does
that applications should not mess with system files, that the
application should be subservient to the OS and not vice versa.

I think there is another side to the coin, too.  I don't know that
much about Oracle, but I know that Oracle is trying to provide a
product to people that works across systems made up of diverse
hardware and software.  If it isn't the case already, it will someday
be the case that your Sun, PC, IBM, etc can all be on the same network
running Oracle, accessing the same database.  Think about trying to
provide a consistent interface between Unix and something like Pick,
which is so different I've never wanted to try to understand it.  It's
no wonder the Oracle people chose to take over administration rather
than requesting it of the OS/administrator.  It makes sense for a big
installation where database use is the big thing.

In the sense that Oracle runs on all these different platforms and is
the one constant in a diverse computing environment, maybe it is
Oracle that is the OS and the lone Unix machine on the end of an IBM
mainframe network is the add-on.

That said, I wish they could find a different way to do it, too.

--
Brad Hines

Jet Propulsion Lab, Pasadena, California

Method 1: Hard
    It would be nice if you could implement this with watchdogs or
    something similar.  You of course want to be able to "vi /etc/passwd"
    and have the result written back into the database, with locking such
    that only one person could open /etc/passwd or the database "rw", then
    "grep foo /etc/passwd" works and everyone is happy (maybe).

    This way you get some of the benefits of using a database and a
    text file all rolled into one.  Of course, it would be nice if the
    watchdog could keep a local copy of what it thinks should be in
    this file in case the network server is down.

Method 2: Easy
    Write programs that extract the data from the database and distribute
    it at some interval (nightly) to all the systems under it's control.
    You can either set this up such that each client requests the data on
    demand or the server force updates on the client.  Or a mixture of both.

    This method requires a lot less code and from my experience updating
    nightly is sufficient.

It makes certain aspects of system administration easier to have a
central database and an EASY way to add/delete user/hosts/etc.  One big
problem is that a central database scheme just won't scale up forever.
How big will your network of systems be in 5 years? 10? 20?
How big were systems 5 years ago? 10? 20?

In my experience we were the ones that maintained the database and that
certainly changes some of the questions (if sysadm people are responsible
for security you don't want people who don't know anything about security
maintaining the database that controls all access to machines on your
network).

BTW: It's not an unreasonable request for (some of) the system administration
people to learn oracle.

First rule of software:  Throw the first one away.
and so on...
I am not an IBM representative and I speak only for myself.

Quote:

> Doing it the other way means that the class of accidents that break
> the database would break all the programs that depend on
> /etc/password, ......

   greg pavlov, fstrf, amherst, ny

   more new text. more new text. more new text.

-Bob Wise

Quote:>Oracle is most likly overkill for the problem. However as a oracle
>application, Sys Admin might be easier and less problem prone than it currently
>is now.
>Kermit Tensmeyer                        | Intergraph Corporation

It's OK for an application to mirror things like /etc/passwd or /etc/<any-
config-file>, but only *mirror* it (i.e. reflect, what authorized institutions
put there).

Since all the well-known *DBMSes run on various platforms, the only way I
could imagine is to call trusted (sic) SA-routines to manage these things
(BTW, did you ever try getpwent() on an IBM 370 running OS/VS ? on VMS ?).

Such interface-routines might be managable in cases of changes in the OS,
or would you prefer to keep track of these changes in the application ?
Also, they could be developed by *authorized* persons.

I only remember an OS update (only a PC box), that added /etc/shadow to
the needed files, and an older app was used to add/delete users .....
I had to do the installation from scratch, re-install the app, get the
application-data from a tape that was 4 weeks old .....

I think, that's sufficient to simply say NO !

But, it would be really *great* to imagine that a fired DBA enters the SQL
Interpreter and says:

delete from <user-table> ; commit ;

Leave the jobs to those who are payed for it; it's far more better to let
them work TOGETHER.

Horst
--
============================================================================
Horst Laumer, Kantstrasse 107, D-1000 Berlin 12 ! Bang-Adress: Junk-Food

UUCP: ..unido!fub!geminix!sunrise.in-berlin.de!hotte

The other, equally important, side of the coin, is that such tools should be
optional, in the case of an installation that does have the luxury of Unix
gurus on staff.  If you have a big system and run a lot of applications,
you're not going to let one of them take over the whole system.  The
application should have documentation of exactly what it needs set up for it,
but it should not have any requirement of ever being root itself, except for
perhaps an install script that the sysadmin can review and ensure it won't
break his/her system (see C-news' doit.root script, for example).

So while such tools are a good idea for single-application boxes, they should
not force you to use them.
--

Geac J&E Systems Ltd.     | uunet!geac!gjetor!adeboer | makes the lies the
Toronto, Ontario, Canada  | #include <disclaimer.h>   | salesman told come true.

Speaking of Oracle for System V/386:

        (1) It requires the Software Development System. This is not
            documented.
        (2) It requires you manually CPIO the floppies into the machine,
            but the CPIO command they give is broken.
        (3) The Makefile for SQL*NET is broken: you have to manually edit
            out the references to the asy library before you can link in
            the Interlan TCP library.
        (4) It requires a particular ethernet card: they couldn't put the
            socket calls in a glue file that can be compiled for your own
            TCP... they're distributed throughout the code, so...
        (5) You have to remove the Intel-supplied network drivers. This is
            not documented.
        (6) You have to add /etc/init.d files, but they're not provided
            in a form that you can drop them in.
        (7) I'm sure there's more, but this is all I can recall off the
            top of my head...

I pity anyone who installs this program without being an experienced UNIX
head. And depending on it to get the system up? Give me a break! I'd rather
replace "passwd" with a csh script!
--

+1 713 274 5180.  'U`  "Have you hugged your wolf today?"