Thread: SELinux strangeness with 8.1.2 and 8.1.3

SELinux strangeness with 8.1.2 and 8.1.3

From
"Just Someone"
Date:
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!

Re: SELinux strangeness with 8.1.2 and 8.1.3

From
Tom Lane
Date:
"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

Re: SELinux strangeness with 8.1.2 and 8.1.3

From
"Just Someone"
Date:
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!

Re: SELinux strangeness with 8.1.2 and 8.1.3

From
Tom Lane
Date:
"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

Re: SELinux strangeness with 8.1.2 and 8.1.3

From
"Just Someone"
Date:
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!

Re: SELinux strangeness with 8.1.2 and 8.1.3

From
"Just Someone"
Date:
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!