[Gnumed-devel] Re: bootstrap*

[Andreas Tille]

[Noel, I just CC you here because I regard you as Debian PostgreSQL
 expert which might have hints regarding this topic.]

On Wed, 29 Jan 2003, Hilmar Berger wrote:

> 3. You can store passwords for postgres and gm-dbowner as clear-text in
> the .conf file which impairs security.
I had some private discussion with Karsten about this topic when I tried
to build Debian-packages from Gnumed.  My preliminary work can be
found at

      http://people.debian.org/~tille/packages/gnumed/

PLEASE NOTE THE BOTTOM OF THIS PAGE and make sure that you understand
that these are not yet finished packages.  It is just the current state
of my work before I'll leave for a two weeks foto trip to Iceland, i.e.
completely offline.
So feel free to have a look at these packages and send me patches which
will be incorporated when I'm back.

Back to the topic of passwords.  At least the Debian flavour of
PostgreSQL has the authentification method "auth" - if I'm not completely
wrong this was adopted upstream.  This works as follows:

   An authenticated system user (say postgres) does not have to
   ship a password to connect to PostgreSQL (if the postgres user
   exists in the DB).  The advantage is that there is no need to
   store any password unencrypted.  For instance:

     # whoami
     root
     # echo "select count(*) from pg_tables ;" | psql template1
     psql: FATAL 1:  user "root" does not exist
     # su postgres
     # echo "select count(*) from pg_tables ;" | psql template1
      count
     -------
         25
     (1 row)
     # exit
     # su other
     # echo "select count(*) from pg_tables ;" | psql template1
     psql: FATAL 1:  user "other" does not exist

   So I did the bootstrap shell script via

   su - postgres -c "/usr/sbin/bootstrap-gm_db_system.py --log-file=${LOGFILE} \
        --conf-file=/etc/gnumed/bootstrap-gm_db_system.conf"

   which enabled me to leave the password for postgres user blank (which
   reduces the number of passwords to store or type in by one).

The problem with the password of gm-dbowner remains.  I had quite a
hacking solution on the harddisk of my Laptop which completely lost
all data yesterday (well it was just the work of 1 hour, so no big
desaster - but this hack is gone away).  I decided just to start a
discussion about the right way to handle this problem.

What are no options in my opinion:

  1. Storing a password anywhere in clear text.  I think even a
     temporary storage sucks. You might think of an interupted
     install procedure and the temporary file might remain anywhere.

  2. Asking the user inside the postinstall script to type in
     password.  This is really bad style.  Debian switched to
     debhelper to do all configuration first and afterwards install
     the whole system without interaction.  So I would hate a
     new package with old style questions at the wrong time.

What are possible ways:

  1. Create a systemuser gm-dbowner.  He might get no login and
     no password as postgres or some other users at Debian system,
     i.e. the only method to become this user is

        # whoami
        root
        # su gm-dbowner

     so you have to know the root password of the box in question
     to become this user.  If this user exists we could start a
     process owned by this user and do the necessary stuff which
     has to be done.

  2. Use debconf database to store the password.  Not: I have to
     make sure that it is save enough.  Root can read this password
     via debconf API which means that it is not MD5 or SHA encrypted,
     but only root can read it.
     If we decide for this method I would try to provide a code
     snipped which returns the password which can be used in the
     bootstrap script.

I would be happy to hear opinions and other suggestions.

Kind regards

        Andreas.