Description of problem: PostgreSQL database initialization fails silently when selinux is in enforcement mode. The problem is that the initdb script uses this construct in several places: postgres <<EOF ... sql commands ... EOF and selinux denies permission to read the here-document. This results in large chunks of needed functionality not being installed. An easy check that it's broken is $ su postgres $ psql -l ERROR: relation "pg_catalog.pg_user" does not exist Version-Release number of selected component (if applicable): selinux-policy-targeted-1.17.30-2.80 postgresql-server-7.4.7-1.FC3.2 How reproducible: 100% Steps to Reproduce: 1. service postgresql stop (if running) 2. rm -rf /var/lib/pgsql/data 3. service postgresql start 4. psql -l Actual results: Expected results: Additional info: This is the same issue that broke mysql (bug #141062) --- I'm surprised it hasn't been reported against postgres earlier. I know I can work around it by hacking the script, but I remain convinced that I should not have to. There is nothing inherently insecure about a here-document; the fact that I can't use one is either a selinux policy bug or a bash bug. I think we are going to keep seeing more and more of this sort of gripe until something is done about it in the policy or in bash.
Well there is not much that can be done by SELinux. Since this is fundamentally an information from from one one security context to another via a file. Now we can give the postgress/mysql access to tmp files created by root in order to make this work, but this significantly lowers the security level of the programs, Since if later on a tmp file is created, a hacked mysql/postgres could read it. By changing it to a cat /tmp/XYZ | postgres type app, we are only handing a file descriptor, to the newly created application which is a lot smaller information flow. If bash was changed to open the file and hand the descriptor that would solve the SELinux problem also.
Perhaps I am missing something, but it seems to me that this can be fixed trivially as long as SELinux can distinguish opening a file from reading/writing a descriptor that is already open. Just allow daemons to read/write files in /tmp only when the descriptor was handed to them already open. BTW, I would like to see the same behavior apply to /dev/tty. The current restriction that daemon programs cannot write on /dev/tty means that interactive error messages from postgres are suppressed, which is VERY user unfriendly, and completely unhelpful from a security standpoint too. As far as your last comment goes, doesn't bash already hand the thing as an opened file descriptor?
*** Bug 152591 has been marked as a duplicate of this bug. ***
Dan asked me to comment on this bug, with the question of: Is there a way to distinguish between having the ability to open a file versus having the file discriptor handed to you by a parent? IE Is there a way we could add an open access type? My answer is below: Only by a change to the SELinux module code. At present, we apply the same set of permission checks for file open, inheriting a descriptor upon execve, and transfer of a descriptor via local IPC. That is consistent with our goals for MAC, i.e. the ability to consistently control the ability of a process to access an object no matter how access is gained. Otherwise, you don't truly have any confinement guarantees; a process can leak a descriptor at will (or by mistake, as happens all too often) to a process that shouldn't have access. We could change the SELinux module code to apply some kind of distinct permission checks upon open vs. inherit/transfer, but that means defining new permissions (and these would be needed for all file classes, and can't modify common file set without compatibility issues), modifying the kernel module code, gettting it all upstreamed, tracking down all the policy changes that are needed, ... Not worth it IMHO.
Well, I've worked around the problem in PostgreSQL, and it looks like we can't have a more general solution :-(
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-433.html