Re: SELinux question

Paul Howarth írta:

Zoltan Boszormenyi wrote:

Paul Howarth írta:

Set yourself up for making local policy modules:

...

Make a local policy module for this issue, in this directory:
1. Create a file postgres.te with this content:

module postgres 0.1;

...

2. Create a file postgres.fc with this content:

/home1/pgsql[^/]*/data(/.*)?
gen_context(system_u:object_r:postgresql_db_t,s0)

/home1/pgsql[^/]*/pgstartup.log    --
gen_context(system_u:object_r:postgresql_log_t,s0)

(that's two long lines)

...

Next, remove any file context objects you added for this issue using
semanage (contexts will now be managed using your local policy module):

# semanage fcontext -d -t postgresql_db_t '/home1/pgsql/data(/.*)?'
# semanage fcontext -d -t postgresql_log_t '/home1/pgsql/pgstartup.log'
# semanage fcontext -d -t postgresql_db_t '/home1/pgsql2/data(/.*)?'

Finally, install your new policy module:

# semodule -i postgres.pp

Thanks, it almost worked. After doing these above,
I still got avc denied { search } messages like this below:

type=AVC msg=audit(1148979521.381:10): avc: denied { search } for pid=2666 comm="postmaster" name="/" dev=sda1 ino=2 scontext=system_u:system_r:postgresql_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=dir

As it turned out, /home1 was default_t and postgresql is not enabled to search

and read files in default_t context. It made it working:

# semanage fcontext -a -t var_lib_t -f -d '/home1'
# fixfiles relabel /home1

You can incorporate this into your local policy module by adding another line to postgres.fc:

/home1(/pgsql)? -d gen_context(system_u:object_r:var_lib_t,s0)

Bump the version number in postgres.te from 0.1 to 0.2 and re-run make.

You could then remove the extra fcontext object using semanage, and update the policy module:

# semodule -i postgres.pp

Having everything in the policy module is better for maintainability I think.

You are right. Thanks.

What puzzled me is starting postgresql failed at boot
but not the manual "service postgresql start" after bootup.
(Maybe different contexts are applied to the logged-in root
and the init program?)

Running the initscript should be exactly the same as the boot process. Starting the service manually (without the initscript) would be different though, as no domain transition would happen.

Both

service postgresql start

and

su - postgres
PGDATA=/home1/pgsql pg_ctl start

(The postgresql initscript uses "runuser" instead of "su" IIRC.)

Do the AVCs logged during the boot process show the process running as postgresql_t? If you do a "ps uaxZ", is it running as postgresql_t or unconfined_t?

It's running under postgresql_t.

The two lines above made it working again.

So it's working from bootup now?

Yes.

An easier way is to bind mount /home/pgsql on /var/lib/pgsql etc. and do

a restorecon -R on the "new" /var/lib/pgsql. That achieves the same
effect without the symlink.

Actually I missed the "bind mount" part. That would have been much easier.

But the crash course in SELinux was most fruitful, thank you.

I've just responded to another poster with almost exactly the same issue. I think this might be worth a wiki page.

It would be a good idea.

Sorry for the late answer, yesterday I donated my blood
and had to hit the bed earlier that my usual.

No problem, we all have to sleep!

Of course :-)

Best regards,
Zoltán Böszörményi