Zoltan Boszormenyi wrote:
Paul Howarth írta:
You must have auditd running (probably a system upgraded from FC4 rather
than a clean FC5 install).
Actually, no. I was a clean install over my previous FC3.
I installed and set auditd to run.
OK. I do this myself too, but most people don't...
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.
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.
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?
The two lines above made it working again.
So it's working from bootup now?
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.
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!
Cheers, Paul.
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
