Who's in charge here: Oracle or Unix?

[Greg Pavlov]

In article <635 at uswnvg.UUCP>, gbarnet at uswnvg.UUCP (Gary Barnette) writes:
> 
> 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. 
> 
  Since you stated your potential "bias", I will state mine: I am responsible
  for a facility whose predominant "services" are electronic mail & communica-
  tions and several moderate-sized database applications.  

  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.

   pavlov at stewart.fstrf.org