During bootup the postgresql server fails to start and produced the following avc denied message:
Jun 15 05:09:12 new2 su(pam_unix)[2414]: session opened for user postgres by (uid=0) Jun 15 05:09:13 new2 kernel: audit(1087290553.569:0): avc: denied { write } for pid=2445 exe=/usr/bin/postgres name=data dev=hda2 ino=788097 scontext=user_u:user_r:user_t tcontext=system_u:object_r:var_lib_t tclass=dir Jun 15 05:09:14 new2 su(pam_unix)[2414]: session closed for user postgres Jun 15 05:09:15 new2 postgresql: Starting postgresql service: failed
This is in enforcing mode with the strict policy selinux-policy-strict-1.13.4-5 Thanks for any help, Richard Hally
On Tue, 15 Jun 2004 19:20, Richard Hally rhallyx@mindspring.com wrote:
During bootup the postgresql server fails to start and produced the following avc denied message:
Jun 15 05:09:12 new2 su(pam_unix)[2414]: session opened for user postgres by (uid=0) Jun 15 05:09:13 new2 kernel: audit(1087290553.569:0): avc: denied { write } for pid=2445 exe=/usr/bin/postgres name=data dev=hda2 ino=788097 scontext=user_u:user_r:user_t tcontext=system_u:object_r:var_lib_t tclass=dir
Have you added the following line to postgresql.fc? /var/lib/pgsql(/.*)? system_u:object_r:postgresql_db_t
As for the source domain being user_t, I'll have to do some tests on that, it's not what's planned. It's probably an unexpected interaction between the recent su changes and the use of su in postgres startup scripts.
Russell Coker wrote:
On Tue, 15 Jun 2004 19:20, Richard Hally rhallyx@mindspring.com wrote:
During bootup the postgresql server fails to start and produced the following avc denied message:
Jun 15 05:09:12 new2 su(pam_unix)[2414]: session opened for user postgres by (uid=0) Jun 15 05:09:13 new2 kernel: audit(1087290553.569:0): avc: denied { write } for pid=2445 exe=/usr/bin/postgres name=data dev=hda2 ino=788097 scontext=user_u:user_r:user_t tcontext=system_u:object_r:var_lib_t tclass=dir
Have you added the following line to postgresql.fc? /var/lib/pgsql(/.*)? system_u:object_r:postgresql_db_t
With the above change to the postgresql.fc I get the following avc denied messages when booting:
Jun 16 00:19:15 new2 su(pam_unix)[2452]: session opened for user postgres by (uid=0) Jun 16 00:19:15 new2 kernel: audit(1087359555.469:0): avc: denied { search } for pid=2453 exe=/bin/su name=pgsql dev=hda2 ino=722952 scontext=system_u:system_r:initrc_su_t tcontext=system_u:object_r:postgresql_db_t tclass=dir Jun 16 00:19:15 new2 kernel: audit(1087359555.496:0): avc: denied { search } for pid=2453 exe=/bin/bash name=pgsql dev=hda2 ino=722952 scontext=user_u:user_r:user_t tcontext=system_u:object_r:postgresql_db_t tclass=dir Jun 16 00:19:15 new2 kernel: audit(1087359555.521:0): avc: denied { search } for pid=2453 exe=/bin/bash name=pgsql dev=hda2 ino=722952 scontext=user_u:user_r:user_t tcontext=system_u:object_r:postgresql_db_t tclass=dir Jun 16 00:19:15 new2 last message repeated 3 times Jun 16 00:19:15 new2 kernel: audit(1087359555.604:0): avc: denied { search } for pid=2453 exe=/bin/bash name=pgsql dev=hda2 ino=722952 scontext=user_u:user_r:user_t tcontext=system_u:object_r:postgresql_db_t tclass=dir Jun 16 00:19:15 new2 kernel: audit(1087359555.674:0): avc: denied { search } for pid=2453 exe=/bin/bash name=pgsql dev=hda2 ino=722952 scontext=user_u:user_r:user_t tcontext=system_u:object_r:postgresql_db_t tclass=dir Jun 16 00:19:15 new2 kernel: audit(1087359555.710:0): avc: denied { search } for pid=2473 exe=/bin/bash name=pgsql dev=hda2 ino=722952 scontext=user_u:user_r:user_t tcontext=system_u:object_r:postgresql_db_t tclass=dir Jun 16 00:19:15 new2 kernel: audit(1087359555.714:0): avc: denied { search } for pid=2484 exe=/bin/sed name=pgsql dev=hda2 ino=722952 scontext=user_u:user_r:user_t tcontext=system_u:object_r:postgresql_db_t tclass=dir Jun 16 00:19:15 new2 su(pam_unix)[2452]: session closed for user postgres Jun 16 00:19:15 new2 kernel: audit(1087359555.993:0): avc: denied { search } for pid=2482 exe=/usr/bin/postgres name=pgsql dev=hda2 ino=722952 scontext=user_u:user_r:user_t tcontext=system_u:object_r:postgresql_db_t tclass=dir Jun 16 00:19:16 new2 postgresql: Starting postgresql service: failed
HTH Richard Hally
On Wed, 16 Jun 2004 00:31:58 -0400 Richard Hally rhallyx@mindspring.com wrote:
With the above change to the postgresql.fc I get the following avc denied messages when booting:
You must add /usr/bin/postgres -- system_u:object_r:postgresql_exec_t to postgresql.fc and , comment out session optional /lib/security/$ISA/pam_selinux.so multiple from /etc/pam.d/su.
Yuichi Nakamura wrote:
On Wed, 16 Jun 2004 00:31:58 -0400 Richard Hally rhallyx@mindspring.com wrote:
With the above change to the postgresql.fc I get the following avc denied messages when booting:
You must add /usr/bin/postgres -- system_u:object_r:postgresql_exec_t to postgresql.fc and , comment out session optional /lib/security/$ISA/pam_selinux.so multiple from /etc/pam.d/su.
Thanks for the reply, it looks to me that the problem is more like the policy and file_contexts were written for the way Debian(or some other distro) installs PostgresSQL and Fedora installs things differently. The most notable is that in the .fc it has the only postgresql_exec_t with a regex for /usr/lib(64)?/postgresql/bin/.* and on Fedora the executables are in /usr/bin. The question I have is: how do we handle these case where different distros put the same files in different places? Do we continue to add to the policy for each different distro?
Richard Hally
Richard Hally wrote:
Yuichi Nakamura wrote:
On Wed, 16 Jun 2004 00:31:58 -0400 Richard Hally rhallyx@mindspring.com wrote:
With the above change to the postgresql.fc I get the following avc denied messages when booting:
You must add /usr/bin/postgres -- system_u:object_r:postgresql_exec_t to postgresql.fc and , comment out session optional /lib/security/$ISA/pam_selinux.so multiple from /etc/pam.d/su.
Thanks for the reply, it looks to me that the problem is more like the policy and file_contexts were written for the way Debian(or some other distro) installs PostgresSQL and Fedora installs things differently. The most notable is that in the .fc it has the only postgresql_exec_t with a regex for /usr/lib(64)?/postgresql/bin/.* and on Fedora the executables are in /usr/bin. The question I have is: how do we handle these case where different distros put the same files in different places? Do we continue to add to the policy for each different distro?
Yes we put the stuff in both places.
Richard Hally
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
Daniel J Walsh wrote:
Richard Hally wrote:
Yuichi Nakamura wrote:
On Wed, 16 Jun 2004 00:31:58 -0400 Richard Hally rhallyx@mindspring.com wrote:
With the above change to the postgresql.fc I get the following avc denied messages when booting:
You must add /usr/bin/postgres -- system_u:object_r:postgresql_exec_t to postgresql.fc and , comment out session optional /lib/security/$ISA/pam_selinux.so multiple from /etc/pam.d/su.
Thanks for the reply, it looks to me that the problem is more like the policy and file_contexts were written for the way Debian(or some other distro) installs PostgresSQL and Fedora installs things differently. The most notable is that in the .fc it has the only postgresql_exec_t with a regex for /usr/lib(64)?/postgresql/bin/.* and on Fedora the executables are in /usr/bin. The question I have is: how do we handle these case where different distros put the same files in different places? Do we continue to add to the policy for each different distro?
Yes we put the stuff in both places.
I added the /usr/bin/postgres postgresql_exec_t file context (and relabeled) and it still would not start when booting. Below are the allow rules(generated by audit2allow) that were necessary to get the server to start. I did not comment out any pam_selinux.so line in /etc/pam.d/su. That doesn't seem like the right thing to do. Thanks, Richard Hally
allow initrc_su_t postgresql_db_t:dir { search }; allow user_t postgresql_db_t:dir { add_name getattr read remove_name search write }; allow user_t postgresql_db_t:file { create getattr read rename unlink write };
Richard Hally wrote:
Daniel J Walsh wrote:
Richard Hally wrote:
Yuichi Nakamura wrote:
On Wed, 16 Jun 2004 00:31:58 -0400 Richard Hally rhallyx@mindspring.com wrote:
With the above change to the postgresql.fc I get the following avc denied messages when booting:
You must add /usr/bin/postgres -- system_u:object_r:postgresql_exec_t to postgresql.fc and , comment out session optional /lib/security/$ISA/pam_selinux.so multiple from /etc/pam.d/su.
Thanks for the reply, it looks to me that the problem is more like the policy and file_contexts were written for the way Debian(or some other distro) installs PostgresSQL and Fedora installs things differently. The most notable is that in the .fc it has the only postgresql_exec_t with a regex for /usr/lib(64)?/postgresql/bin/.* and on Fedora the executables are in /usr/bin. The question I have is: how do we handle these case where different distros put the same files in different places? Do we continue to add to the policy for each different distro?
Yes we put the stuff in both places.
I added the /usr/bin/postgres postgresql_exec_t file context (and relabeled) and it still would not start when booting. Below are the allow rules(generated by audit2allow) that were necessary to get the server to start. I did not comment out any pam_selinux.so line in /etc/pam.d/su. That doesn't seem like the right thing to do. Thanks, Richard Hally
allow initrc_su_t postgresql_db_t:dir { search }; allow user_t postgresql_db_t:dir { add_name getattr read remove_name search write }; allow user_t postgresql_db_t:file { create getattr read rename unlink write };
You need to setup a server user that can transition to postgresql. A transition never happened.
Dan
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
The following is procedure to run postgresql on my Fedora Core2.
(1) Add following to postgresql.te and postgresql.fc. I created new type "postgresql_dir_t" for default type of /var/lib/postgresql.
# postgresql.te type postgresql_dir_t,file_type,sysadmfile; file_type_auto_trans(postgresql_t,postgresql_dir_t,postgresql_var_run_t) r_dir_file(postgresql_t,postgresql_dir_t)
# postgresql.fc /usr/bin/postgres -- system_u:object_r:postgresql_exec_t /var/lib/pgsql(/.*)? system_u:object_r:postgresql_dir_t /var/lib/pgsql/data(/.*)+ system_u:object_r:postgresql_etc_t /var/lib/pgsql/data/postmaster.pid system_u:object_r:postgresql_var_run_t /var/lib/pgsql/data/base(/.*)? system_u:object_r:postgresql_db_t /var/lib/pgsql/data/global(/.*)? system_u:object_r:postgresql_db_t /var/lib/pgsql/data/pg_xlog(/.*)? system_u:object_r:postgresql_db_t /var/lib/pgsql/data/pg_clog(/.*)? system_u:object_r:postgresql_db_t /var/lib/pgsql/data/postmaster.opts system_u:object_r:postgresql_db_t /etc/sysconfig/pgsql(/.*)? system_u:object_r:postgresql_etc_t /usr/share/pgsql(/.*)? system_u:object_r:postgresql_etc_t /var/log/pgsql.* -- system_u:object_r:postgresql_log_t
(2) reload and relabel # make reload relabel
(3) comment out "session optional /lib/security/$ISA/pam_selinux.so multiple" from /etc/pam.d/su.
Commenting out /etc/pam.d/su is necessary. Without it, postgreSQL(postmaster) will run as "user_t" domain, this domain is for user shell. user_t is not desireble for postgresql.
(4) start postgreSQL #/etc/rc.d/init.d/postgresql start At first time to start postgresql, several new files will be created under /var/lib/pgsql/.
(5) New files under /var/lib/pgsql do not have proper context, so stop postgreSQL and relabel /var/lib/pgsql.
# /etc/rc.d/init.d/postgres stop # setfiles /etc/security/selinux/file_contexts /var/lib
Next time you run postgresql, postgresql will run as "postgresql_t" correctly.
Richard Hally rhally@mindspring.com wrote:
Daniel J Walsh wrote:
Richard Hally wrote:
Yuichi Nakamura wrote:
On Wed, 16 Jun 2004 00:31:58 -0400 Richard Hally rhallyx@mindspring.com wrote:
With the above change to the postgresql.fc I get the following avc denied messages when booting:
You must add /usr/bin/postgres -- system_u:object_r:postgresql_exec_t to postgresql.fc and , comment out session optional /lib/security/$ISA/pam_selinux.so multiple from /etc/pam.d/su.
Thanks for the reply, it looks to me that the problem is more like the policy and file_contexts were written for the way Debian(or some other distro) installs PostgresSQL and Fedora installs things differently. The most notable is that in the .fc it has the only postgresql_exec_t with a regex for /usr/lib(64)?/postgresql/bin/.* and on Fedora the executables are in /usr/bin. The question I have is: how do we handle these case where different distros put the same files in different places? Do we continue to add to the policy for each different distro?
Yes we put the stuff in both places.
I added the /usr/bin/postgres postgresql_exec_t file context (and relabeled) and it still would not start when booting. Below are the allow rules(generated by audit2allow) that were necessary to get the server to start. I did not comment out any pam_selinux.so line in /etc/pam.d/su. That doesn't seem like the right thing to do. Thanks, Richard Hally
allow initrc_su_t postgresql_db_t:dir { search }; allow user_t postgresql_db_t:dir { add_name getattr read remove_name search write }; allow user_t postgresql_db_t:file { create getattr read rename unlink write };
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
--- Yuichi Nakamura Japan SELinux Users Group(JPSEG) http://www.selinux.gr.jp/
Let's get back to basics and look at the concepts rather than AVC messages.
/etc/rc.d/init.d/postgresql uses su to change uid to start the daemon, this is a problem as it's not compatible with the usual su operation. Changing su is not the right solution as we don't even need 1% of the functionality of su, all we need is a way to call setregid() and setreuid() before executing the script. I'm not sure if we already have a program we can use for this purpose (sudo is not suitable). For a test I spent 30 minutes writing a program that provides all of the su functionality we need for such things, we'll have to include that program if we don't have something better (we should have something better).
/etc/rc.d/init.d/postgresql does lots of things other than just starting a daemon, for example the code after: echo -n $"Initializing database: "
I tried labelling /etc/rc.d/init.d/postgresql as postgresql_exec_t, however the postgresql_t domain does not have access to write to the administrator console (and such access is not desired), it does not have access to rhgb_t, and there's some other things it needs access to.
I think that perhaps the correct thing to do is to re-write /etc/rc.d/init.d/postgresql to call a separate script with type postgresql_exec_t to do the "Initializing database" thing. I'll look into that tomorrow.
Russell Coker wrote:
Let's get back to basics and look at the concepts rather than AVC messages.
/etc/rc.d/init.d/postgresql uses su to change uid to start the daemon, this is a problem as it's not compatible with the usual su operation.
Huh? su (Substitute User) has been to "Change the effective userid and group id" since I first learned about it in 1978. And is being used for that purpose in the init.d/postgresql stript.
Changing su is not the right solution
Agree.
Perhaps we need to look at pam_selinux again rather than trying to change the init.d/postgresql script?
as we don't even need 1% of the functionality of su,
all we need is a way to call setregid() and setreuid() before executing the script. I'm not sure if we already have a program we can use for this purpose (sudo is not suitable). For a test I spent 30 minutes writing a program that provides all of the su functionality we need for such things, we'll have to include that program if we don't have something better (we should have something better).
/etc/rc.d/init.d/postgresql does lots of things other than just starting a daemon, for example the code after: echo -n $"Initializing database: "
Maybe we need a restorecon where it creates the data directory(if not already present (a rare occurance)). The real work part of initializing the data directory is done with "su -l postgres -c ..." just like the part that starts the server(i.e. su -l postgres -c ...)
What is it about pam_selinux that is causing the problem? With your latest changes to postgresql.fc and a couple of allow rules, the server starts in the correct context when booting if the pam_selinux line is commented out of pam.d/su. That would indicate to me that there is something about pam_selinux that is the problem. The error message is: "Unable to get valid context for postgres, no valid tty" Perhaps the problem has to do with the 'no valid tty' part?
Thanks for your help, Richard Hally
On Sat, 3 Jul 2004 09:39, Richard Hally rhally@mindspring.com wrote:
Russell Coker wrote:
Let's get back to basics and look at the concepts rather than AVC messages.
/etc/rc.d/init.d/postgresql uses su to change uid to start the daemon, this is a problem as it's not compatible with the usual su operation.
Huh? su (Substitute User) has been to "Change the effective userid and group id" since I first learned about it in 1978. And is being used for that purpose in the init.d/postgresql stript.
It's purpose is to change the effective UID/GID for interactive sessions.
From su(1) on Fedora:
su - run a shell with substitute user and group IDs
From su(1) on Debian:
su is used to become another user during a login session.
There's no mention I could find in the documentation of using su for starting daemons.
I think that there is no good reason for using su in this manner, and some good reasons for not doing so. The postgresql start scripts will have to be changed.
/etc/rc.d/init.d/postgresql does lots of things other than just starting a daemon, for example the code after: echo -n $"Initializing database: "
Maybe we need a restorecon where it creates the data directory(if not already present (a rare occurance)).
It might be rare in terms of the number of times the daemon is started, but from my understanding of the script it's expected to be done the first time the daemon is started. So it's inevitable that it happens at least once, and therefore we have to handle it.
The real work part of initializing the data directory is done with "su -l postgres -c ..." just like the part that starts the server(i.e. su -l postgres -c ...)
What is it about pam_selinux that is causing the problem?
The fact that there is no identity, role, and domain defined for Postgres. We can configure the SE Linux policy to allow this, but it's the wrong approach.
Russell Coker wrote:
On Sat, 3 Jul 2004 09:39, Richard Hally rhally@mindspring.com wrote:
Russell Coker wrote:
Let's get back to basics and look at the concepts rather than AVC messages.
/etc/rc.d/init.d/postgresql uses su to change uid to start the daemon, this is a problem as it's not compatible with the usual su operation.
Huh? su (Substitute User) has been to "Change the effective userid and group id" since I first learned about it in 1978. And is being used for that purpose in the init.d/postgresql stript.
It's purpose is to change the effective UID/GID for interactive sessions.
From su(1) on Fedora:
su - run a shell with substitute user and group IDs
From su(1) on Debian:
su is used to become another user during a login session.
There's no mention I could find in the documentation of using su for starting daemons.
I think that there is no good reason for using su in this manner, and some good reasons for not doing so. The postgresql start scripts will have to be changed.
/etc/rc.d/init.d/postgresql does lots of things other than just starting a daemon, for example the code after: echo -n $"Initializing database: "
Maybe we need a restorecon where it creates the data directory(if not already present (a rare occurance)).
It might be rare in terms of the number of times the daemon is started, but from my understanding of the script it's expected to be done the first time the daemon is started. So it's inevitable that it happens at least once, and therefore we have to handle it.
The real work part of initializing the data directory is done with "su -l postgres -c ..." just like the part that starts the server(i.e. su -l postgres -c ...)
What is it about pam_selinux that is causing the problem?
The fact that there is no identity, role, and domain defined for Postgres. We can configure the SE Linux policy to allow this, but it's the wrong approach.
Ok, now I understand making a distinction about using su for starting a deamon. What is the problem with defining a user role for postgres? And how would one go about doing that?
TFTH Richard Hally
On Fri, 2004-07-02 at 19:39, Richard Hally wrote:
Perhaps we need to look at pam_selinux again rather than trying to change the init.d/postgresql script?
<snip>
What is it about pam_selinux that is causing the problem? With your latest changes to postgresql.fc and a couple of allow rules, the server starts in the correct context when booting if the pam_selinux line is commented out of pam.d/su. That would indicate to me that there is something about pam_selinux that is the problem. The error message is: "Unable to get valid context for postgres, no valid tty" Perhaps the problem has to do with the 'no valid tty' part?
pam_selinux is merely asking for a reachable security context for the new user identity from the current security context. The problem is that the SELinux policy has no user identities for these pseudo users, and it isn't clear that we truly want to go down the path of adding them (as has been done for some users in the policy/serviceusers files).
Russell Coker wrote:
Let's get back to basics and look at the concepts rather than AVC messages.
Another way of looking at the problem is that with the three allow rules below the server *will* start but it has a context of user_u:user_r:user_t. When it is started without the pam_selinux line in pam.d/su, the context is system_u:system_r:postgresql_t.
Dan Walsh said:
You need to setup a server user that can transition to postgresql. A transition never happened.
Dan
Here are the three allow rules:
allow initrc_su_t postgresql_db_t:dir { search }; allow user_t postgresql_db_t:dir { add_name getattr read remove_name search write }; allow user_t postgresql_db_t:file { create getattr read rename unlink write };
Thanks for the help, Richard Hally
On Fri, 2004-07-02 at 10:33, Russell Coker wrote:
Let's get back to basics and look at the concepts rather than AVC messages.
/etc/rc.d/init.d/postgresql uses su to change uid to start the daemon, this is a problem as it's not compatible with the usual su operation. Changing su is not the right solution as we don't even need 1% of the functionality of su, all we need is a way to call setregid() and setreuid() before executing the script. I'm not sure if we already have a program we can use for this purpose (sudo is not suitable).
The daemon() macro in /etc/init.d/functions includes a --user option that causes it to run the command via su in the specified user identity (su -s /bin/bash - $user -c ...). So it appears that this is not an uncommon/unexpected practice for running daemons in a non-root uid without requiring a separate wrapper program.
Richard Hally wrote:
Yuichi Nakamura wrote:
On Wed, 16 Jun 2004 00:31:58 -0400 Richard Hally rhallyx@mindspring.com wrote:
With the above change to the postgresql.fc I get the following avc denied messages when booting:
You must add /usr/bin/postgres -- system_u:object_r:postgresql_exec_t to postgresql.fc and , comment out session optional /lib/security/$ISA/pam_selinux.so multiple from /etc/pam.d/su.
Thanks for the reply, it looks to me that the problem is more like the policy and file_contexts were written for the way Debian(or some other distro) installs PostgresSQL and Fedora installs things differently. The most notable is that in the .fc it has the only postgresql_exec_t with a regex for /usr/lib(64)?/postgresql/bin/.* and on Fedora the executables are in /usr/bin. The question I have is: how do we handle these case where different distros put the same files in different places? Do we continue to add to the policy for each different distro?
Richard Hally
Added the following. Please check since I know nothing about postgresql.
# # Files from postgresql # /usr/bin/clusterdb -- system_u:object_r:postgresql_exec_t /usr/bin/createdb -- system_u:object_r:postgresql_exec_t /usr/bin/createlang -- system_u:object_r:postgresql_exec_t /usr/bin/createuser -- system_u:object_r:postgresql_exec_t /usr/bin/dropdb -- system_u:object_r:postgresql_exec_t /usr/bin/droplang -- system_u:object_r:postgresql_exec_t /usr/bin/dropuser -- system_u:object_r:postgresql_exec_t /usr/bin/pg_dump -- system_u:object_r:postgresql_exec_t /usr/bin/pg_dumpall -- system_u:object_r:postgresql_exec_t /usr/bin/pg_encoding -- system_u:object_r:postgresql_exec_t /usr/bin/pg_id -- system_u:object_r:postgresql_exec_t /usr/bin/pg_restore -- system_u:object_r:postgresql_exec_t /usr/bin/psql -- system_u:object_r:postgresql_exec_t /usr/bin/vacuumdb -- system_u:object_r:postgresql_exec_t # # Files from postgresql-server # /usr/bin/initdb -- system_u:object_r:postgresql_exec_t /usr/bin/initlocation -- system_u:object_r:postgresql_exec_t /usr/bin/ipcclean -- system_u:object_r:postgresql_exec_t /usr/bin/pg_controldata -- system_u:object_r:postgresql_exec_t /usr/bin/pg_ctl -- system_u:object_r:postgresql_exec_t /usr/bin/pg_resetxlog -- system_u:object_r:postgresql_exec_t /usr/bin/postgres -- system_u:object_r:postgresql_exec_t /usr/bin/postmaster -- system_u:object_r:postgresql_exec_t
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Thu, 1 Jul 2004 21:52, Daniel J Walsh dwalsh@redhat.com wrote:
Added the following. Please check since I know nothing about postgresql.
I am not a postgresql expert either. However i think that some of these aren't needed.
# # Files from postgresql # /usr/bin/clusterdb -- system_u:object_r:postgresql_exec_t /usr/bin/createdb -- system_u:object_r:postgresql_exec_t /usr/bin/createuser -- system_u:object_r:postgresql_exec_t /usr/bin/dropdb -- system_u:object_r:postgresql_exec_t /usr/bin/dropuser -- system_u:object_r:postgresql_exec_t /usr/bin/psql -- system_u:object_r:postgresql_exec_t /usr/bin/vacuumdb -- system_u:object_r:postgresql_exec_t
The above are just wrappers for SQL commands. I don't think that there's any benefit in labelling them, and there may be some disadvantages for some of them (think of SQL scripts that need read/write access to files that the calling domain accesses).
/usr/bin/createlang -- system_u:object_r:postgresql_exec_t /usr/bin/droplang -- system_u:object_r:postgresql_exec_t /usr/bin/pg_encoding -- system_u:object_r:postgresql_exec_t /usr/bin/pg_id -- system_u:object_r:postgresql_exec_t /usr/bin/pg_restore -- system_u:object_r:postgresql_exec_t
I am unsure about the above. Either the documentation or my understanding is lacking.
/usr/bin/pg_dump -- system_u:object_r:postgresql_exec_t /usr/bin/pg_dumpall -- system_u:object_r:postgresql_exec_t
The above definitely need labelling.
/usr/bin/initdb -- system_u:object_r:postgresql_exec_t
initdb is just a shell script. Maybe it should be left unlabeled and just have transitions when it runs /usr/bin/postgres?
/usr/bin/ipcclean -- system_u:object_r:postgresql_exec_t
This shell script refuses to run as root, probably doesn't need a special label.
/usr/bin/pg_controldata -- system_u:object_r:postgresql_exec_t
Displays stuff from initdb. If initdb doesn't need it then it probably doesn't either.
/usr/bin/pg_ctl -- system_u:object_r:postgresql_exec_t
Runs "postmaster" which is a symlink to "postgres", so it shouldn't need a label.
/usr/bin/pg_resetxlog -- system_u:object_r:postgresql_exec_t
This one is not clear to me, but I think for the moment it should be labelled.
/usr/bin/postgres -- system_u:object_r:postgresql_exec_t
Definately needs labelling.
/usr/bin/postmaster -- system_u:object_r:postgresql_exec_t
No such file.
Please try out the attached postgresql.fc file, I'm sure it will work at least as well as anything that anyone else has posted, and probably better than most.
I'll review Yuichi's labelling ideas for the data directory later.
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Richard Hally -
Richard Hally -
Russell Coker -
Stephen Smalley -
Yuichi Nakamura -
Yuichi Nakamura