Thread: SELinux strangeness with 8.1.2 and 8.1.3
Hi, I know this isn't directly a postgres issue, but it might help a few other users, so here goes. I did an upgrade on my Fedora Core 4 system, and postgres (8.1.2 from the postgres packages, not FC packages) stopped working because of permission issues when trying to create postmaster.pid in the /var/lib/pgsql/data directory. My system has SELinux active, and it used to work until now. So I upgraded using the latest 8.1.3 release (I built it from SRPMs as an x86_64 binary wasn't available), hoping it will help. It didn't. I researched it a bit, and tried a few things, and discovered that the problem is in the init script at /etc/init.d/postgres users runuser instead of su on SELinux enabled systems. But for some reason it won't work this way. I manually reveted it to use su and it works fine. It anyone knows of a better fix - please let me know. Thanks, Guy. --- Family management on postgres+rails: http://www.famundo.com - coming soon!
"Just Someone" <just.some@gmail.com> writes:
> I researched it a bit, and tried a few things, and discovered that the
> problem is in the init script at /etc/init.d/postgres users runuser
> instead of su on SELinux enabled systems. But for some reason it won't
> work this way. I manually reveted it to use su and it works fine.
I don't think I believe this ... not least because the runuser-for-su
substitution has been in there for a long time. It doesn't explain
a breakage during an FC4 update.
Can you provide a reasonably self-contained demonstration of the problem
you saw?
regards, tom lane
Hi Tom, I looked into another system I have and after updating FC4 to the latest and installing the latest from the PGDG srpms, I didn't have this problem. Tomorrow I'm going to do a similar test on another server that I have to install Postgres on. I will report back with what I find on it. But on this machine the change to su solved the issue. Some more clues that might help you see if there's a real problem, is that the /var/lib/pgsql/data/postmaster.pid file is created with the a SELinux context that's different from the rest. It is created with system_u:object_r:file_t while the rest of the files are created with root:object_r:postgresql_db_t. And the postmaster (when using runuser) fails on accessing it according to the audit log. The file is created but it's empty. So the failure is when trying to write the pid and the rest of the info to it. When I run with su, it is be able to access it just fine. I retested now just to make sure I wasn't seeing things. Some more info about the system: * FC4 fully updated * Postgres 8.1.3 built from the PGDG SRPMs * Dual Opteron * 4GB RAM * /var/lib/pgsql/data on a RAID10 with xfs on top * WAL on a different RAID on a partition only for itself with ext2 * SELinux in targeted policy mode Bye, Guy. On 3/1/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Just Someone" <just.some@gmail.com> writes: > > I researched it a bit, and tried a few things, and discovered that the > > problem is in the init script at /etc/init.d/postgres users runuser > > instead of su on SELinux enabled systems. But for some reason it won't > > work this way. I manually reveted it to use su and it works fine. > > I don't think I believe this ... not least because the runuser-for-su > substitution has been in there for a long time. It doesn't explain > a breakage during an FC4 update. > > Can you provide a reasonably self-contained demonstration of the problem > you saw? > > regards, tom lane > -- Bye, Guy Family management on rails: http://www.famundo.com - coming soon!
"Just Someone" <just.some@gmail.com> writes:
> Some more clues that might help you see if there's a real problem, is
> that the /var/lib/pgsql/data/postmaster.pid file is created with the a
> SELinux context that's different from the rest. It is created with
> system_u:object_r:file_t while the rest of the files are created with
> root:object_r:postgresql_db_t. And the postmaster (when using runuser)
> fails on accessing it according to the audit log.
Hmm. That seems like a SELinux policy bug. It doesn't happen for me:
the pid file is created with the same context the other files have.
-rw------- postgres postgres root:object_r:postgresql_db_t postmaster.pid
Are you sure that your SELinux policy is up-to-date? Maybe you need to
do a restorecon on the postgres binaries and/or /var/lib/pgsql/data.
> Some more info about the system:
> * FC4 fully updated
> * Postgres 8.1.3 built from the PGDG SRPMs
> * Dual Opteron
I tried it myself on a freshly-updated FC4 x86_64 system, using the current
FC5 SRPMs, and couldn't see a problem. Red Hat's SRPMs are not exactly
like the PGDG ones, but the only difference I can find that looks at all
relevant to SELinux is this one in the init script:
132c134
< [ -x /usr/bin/chcon ] && /usr/bin/chcon -u system_u -r object_r -t postgresql_log_t "$PGLOG"
---
> [ -x /usr/bin/chcon ] && /usr/bin/chcon -t postgresql_log_t "$PGLOG"
and that's not about the pid file.
regards, tom lane
Hi Tom, > Hmm. That seems like a SELinux policy bug. It doesn't happen for me: > the pid file is created with the same context the other files have. I agree! I have the latest FC4 policy update. So I downloaded the sources as the new one didn't solve the issue. The policy source has no mention on the pid file, but it seems like it should be created with the settings of the directory, which is set correctly. I'm not an expert in SELinux, so I didn't want to mess with the policy, though I think the pid file could be added to the policy specifically to solve this issue. Also, I did run restorecon on the directory (that was the first thing I tried), but it didn't help. Probably because the pid file isn't there when postgres isn't running. Today I will have the results from my second machine update, as it just finished installing all the FC4 updates through yum. I'll let you know how it goes. Bye, Guy. > > -rw------- postgres postgres root:object_r:postgresql_db_t postmaster.pid > > Are you sure that your SELinux policy is up-to-date? Maybe you need to > do a restorecon on the postgres binaries and/or /var/lib/pgsql/data. > > > Some more info about the system: > > * FC4 fully updated > > * Postgres 8.1.3 built from the PGDG SRPMs > > * Dual Opteron > > I tried it myself on a freshly-updated FC4 x86_64 system, using the current > FC5 SRPMs, and couldn't see a problem. Red Hat's SRPMs are not exactly > like the PGDG ones, but the only difference I can find that looks at all > relevant to SELinux is this one in the init script: > > 132c134 > < [ -x /usr/bin/chcon ] && /usr/bin/chcon -u system_u -r object_r -t postgresql_log_t "$PGLOG" > --- > > [ -x /usr/bin/chcon ] && /usr/bin/chcon -t postgresql_log_t "$PGLOG" > > and that's not about the pid file. > > regards, tom lane > -- Bye, Guy Family management on rails: http://www.famundo.com - coming soon!
I just finished installing the PGDG rpms on my second server. This one is a single CPU Opteron with 2 SATA based RAID5 arrays. (Just to clear things up, I know RAID5 is bad for postgres, but this is a storage server that has postgres only as a backup for the main machine.) The problem diesn'[t happen on this second machine. Which leaves me with one big difference between the two machines. The main DB server (the one with the problem) has the RAID10 array mounted exclusively for it's access, and under it the pg_xlog directory is mounted on another exclusive partition on the other array. Here are the mount details: /dev/sdb1 on /var/lib/pgsql type xfs (rw,noatime,nodiratime,logbufs=8) /dev/sda3 on /var/lib/pgsql/data/pg_xlog type ext2 (rw,noatime,nodiratime) Any idea if this might be causing the problem? I don't see how it might do it, but as I said I'm not an SELinux expert. Bye, Guy. On 3/3/06, Just Someone <just.some@gmail.com> wrote: > Hi Tom, > > > Hmm. That seems like a SELinux policy bug. It doesn't happen for me: > > the pid file is created with the same context the other files have. > > I agree! I have the latest FC4 policy update. So I downloaded the > sources as the new one didn't solve the issue. The policy source has > no mention on the pid file, but it seems like it should be created > with the settings of the directory, which is set correctly. I'm not an > expert in SELinux, so I didn't want to mess with the policy, though I > think the pid file could be added to the policy specifically to solve > this issue. Also, I did run restorecon on the directory (that was the > first thing I tried), but it didn't help. Probably because the pid > file isn't there when postgres isn't running. > > Today I will have the results from my second machine update, as it > just finished installing all the FC4 updates through yum. I'll let you > know how it goes. > > Bye, > > Guy. > > > > > -rw------- postgres postgres root:object_r:postgresql_db_t postmaster.pid > > > > Are you sure that your SELinux policy is up-to-date? Maybe you need to > > do a restorecon on the postgres binaries and/or /var/lib/pgsql/data. > > > > > Some more info about the system: > > > * FC4 fully updated > > > * Postgres 8.1.3 built from the PGDG SRPMs > > > * Dual Opteron > > > > I tried it myself on a freshly-updated FC4 x86_64 system, using the current > > FC5 SRPMs, and couldn't see a problem. Red Hat's SRPMs are not exactly > > like the PGDG ones, but the only difference I can find that looks at all > > relevant to SELinux is this one in the init script: > > > > 132c134 > > < [ -x /usr/bin/chcon ] && /usr/bin/chcon -u system_u -r object_r -t postgresql_log_t "$PGLOG" > > --- > > > [ -x /usr/bin/chcon ] && /usr/bin/chcon -t postgresql_log_t "$PGLOG" > > > > and that's not about the pid file. > > > > regards, tom lane > > > > > -- > Bye, > > Guy > > Family management on rails: http://www.famundo.com - coming soon! > -- Bye, Guy Family management on rails: http://www.famundo.com - coming soon!