Re: sepgsql contrib module - Mailing list pgsql-hackers

(2010/12/24 11:53), KaiGai Kohei wrote:
> There is one another issue to be discussed.
> We need a special form of regression test. Because SE-PostgreSQL
> makes access control decision based on security label of the peer
> process, we need to switch psql process during regression test.
> (So, I don't include test cases yet.)
>
> We have 'runcon' command to launch a child process with specified
> security label as long as the security policy allows. If we could
> launch 'psql' by 'runcon' with specified label, we can describe
> test-cases on the existing framework on 'make installcheck'.
>
> An idea is to add an option to pg_regress to launch psql command
> with a specified wrapper program (like 'runcon').
> In this case, each contrib modules kicks with REGRESS_OPTS setting.
> One thing to be considered is the security label to be given to
> the 'runcon' is flexible for each *.sql files.
>
The attached patch adds --launcher=COMMAND option to pg_regress.
If a command was specified, pg_regress prepends the specified
command string in front of psql command.

When we use this option, psql command process will launched via
the launcher program. Of course, the launcher has responsibility
to execute psql correctly.)

This example is a case when I run a regression test on cube module.
It tries to launch psql using 'runcon -l s0'.

  [kaigai@saba cube]$ make installcheck REGRESS_OPTS="--launcher='runcon -l s0' --dbname=cube_regress"
  make -C ../../src/test/regress pg_regress
  make[1]: Entering directory `/home/kaigai/repo/pgsql/src/test/regress'
  make -C ../../../src/port all
  make[2]: Entering directory `/home/kaigai/repo/pgsql/src/port'
  make[2]: Nothing to be done for `all'.
  make[2]: Leaving directory `/home/kaigai/repo/pgsql/src/port'
  make[1]: Leaving directory `/home/kaigai/repo/pgsql/src/test/regress'
  ../../src/test/regress/pg_regress --inputdir=. --psqldir=/usr/local/pgsql/bin --launcher='runcon -l s0'
--dbname=cube_regresscube 
  (using postmaster on Unix socket, default port)
  ============== dropping database "cube_regress"       ==============
  DROP DATABASE
  ============== creating database "cube_regress"       ==============
  CREATE DATABASE
  ALTER DATABASE
  ============== running regression test queries        ==============
  test cube                     ... ok

  =====================
   All 1 tests passed.
  =====================

During the regression test, I checked security context of the process.

  [kaigai@saba ~]$ env LANG=C pstree -Z
  systemd(`system_u:system_r:init_t:s0')
   :
   |-sshd(`unconfined_u:system_r:sshd_t:s0-s0:c0.c1023')
   |  |-sshd(`unconfined_u:system_r:sshd_t:s0-s0:c0.c1023')
   |  |  `-sshd(`unconfined_u:system_r:sshd_t:s0-s0:c0.c1023')
   |  |     `-bash(`unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023')
   |  |        `-make(`unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023')
   |  |           `-pg_regress(`unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023')
   |  |              `-psql(`unconfined_u:unconfined_r:unconfined_t:s0')

It shows us the launcher program drops privileges of "c0.c1023" on end of
the security label of processes between pg_regress and psql.

How about the idea to implement regression test for SE-PostgreSQL, or
possible other stuff which depends on environment variables.

Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>