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
started successfully if I logged in as root or under "su -" from my
mortal uid.
(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
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
