In-Reply-To: <199807231225.FAA16681@shell17.ba.best.com>

First I want to say your answer bought up some interesting aspects and
I want to answer some spontan ideas, but I haven't the time to work it
out in more detail. At least in the near future.

Todd Whitesel <toddpw@best.com> wrote:

...
> There is also the legwork of collecting information about all the diverse
> hardware out there. It would be really cool to have a system so that when
> you get a new piece of hardware, you can look out across the net for
> settings that other people said worked for them, and once you find a
> setting that works for you, you can send it to the database and it gets
> recorded for future searches. I first thought of this while pondering all
> the pain and suffering caused by disk drive geometries, but it generalizes.

Do you think of a network searchable database? I am not shure that
"getcap" will be realy good for this. But I have seen a implementation
of a distributed refer database, whith data replication.

...

> There are many services that deserve this treatment. However I would like
> to advise against an automatic proliferation of new /etc files.

I also think puting more and more files into /etc is not a good idea, but
we need a central place to put the standard values in. Maybe the should
go to /usr/share/ or /usr/etc, if the are not need to boot the system. If
"lpd" id in /usr/sbin "printcap" should also go to /usr/<anywhere>.

> I feel very strongly that, in the long term, the majority of the system
> installation should be mounted read-only and normally only modified by
> 'sysinst' or while in single-user mode. System configuration needs to be
> partitioned so that non-critical devices and system options can be set up
> by Lusers. A litmus test case is that unless an administrator specifically
> disallows it, non-root users should be allowed to invoke 'newfs' and 'mount'
> on a ZIP disk, or a USB floppy drive.

You are right, it will be easy with termcap and most other capability
databases. Maybe there could be a better support for searching several
places for the capability database in "getcap". As fare I know "printcap"
is locked to "/etc/printcap" without a $HOME/.princap extetion, because
of accounting. Your request to mount would need a major redesign of
/etc/fstab and mount, because this would open many secutity holes
otherwise. I.e.:
  cp /bin/sh to $ZIP/sh;
  chown root $ZIP/sh;
  chmod a+s $ZIP/sh;
  unmount $ZIP;
  #go to a system with ZIP and you are not root
  mount $ZIP;
  $ZIP/sh; #you are root now;

...

> Now imagine using this infrastructure to control access to printers. It's
> easy for someone to plug in a USB printer and enable it in ~/.etc/printcap
> so no one else sees it, or in a systemwide printcap file. Printers managed by
> the IT department can be exposed to the entire network via NIS-style pushing.
> Default printer aliases to the physically closest printer could be set at any
> of the various levels depending on security/flexibility concerns.

You are right, but wouldn't it be the best it goes into "getcap" and
work not only for printers, terminal (termcap), but also for all other
capability databases we have (like formats for floppies, disklabels, ...).

I know of two database formats we use for system configuration today:

  1. /etc/passwd-format an ASCII-file with fielddelemitter (":") and
     rowdelemitter ("\n"). The Delemitters vary in /etc/fstab, but the
     basic format is the same.

  2. The termcap-format with names types and values, inherence
     (:tc=-entrys). Where we have getcap as application neutral access
     library.

For your wishes we should also have an aplicationneutral interface for
the first database format and hide in both formats the phyiscal
distribution in the data access library as good as posible. But this
would be a biger part of design work.

Bernd Salbrechter

PS.: Someone asked in an other mail for something other than printcap
with longer names.  If we used getcap to access it, longer names would
be no problem. But the longer names would require to change all existing
printcap files, becaus an entry must have one and only one name.