Thread: BUG #11365: denied apache cgi connect
The following bug has been logged on the website:
Bug reference: 11365
Logged by: chenchunling
Email address: chenchuanling@msn.com
PostgreSQL version: 9.3.5
Operating system: centos6.3
Description:
Centos 6.3 integrated 8.4.11 version no problem,but upgrade to version 9.3.5
apache cgi connection denied.Must be set: setenforce 0, such ability can
be.
selinux log:
Sep 6 20:39:55 test kernel: type=1400 audit(1410050395.142:792): avc:
denied { connectto } for pid=9559 comm="servergi"
path="/tmp/.s.PGSQL.5432"
scontext=unconfined_u:system_r:httpd_sys_script_t:s0
tcontext=unconfined_u:system_r:initrc_t:s0 tclass=unix_stream_socket
Sep 6 20:39:55 test kernel: type=1400 audit(1410050395.144:793): avc:
denied { connectto } for pid=9559 comm="servergi"
path="/tmp/.s.PGSQL.5432"
scontext=unconfined_u:system_r:httpd_sys_script_t:s0
tcontext=unconfined_u:system_r:initrc_t:s0 tclass=unix_stream_socket
chenchuanling@msn.com writes:
> Centos 6.3 integrated 8.4.11 version no problem,but upgrade to version 9.3.5
> apache cgi connection denied.Must be set: setenforce 0, such ability can
> be.
That's not something the PG community can do anything about. If there's a
bug in the SELinux policy for apache, you need to complain to Red Hat to
get it fixed.
I suspect though that if you dig a little bit, you will find that this
case has been foreseen, and there's a SELinux policy boolean that you
are supposed to set to allow apache processes to do database access.
A quick browse in the output of "semanage boolean -l" suggests that
"allow_user_postgresql_connect" might be the right thing, or maybe
"httpd_can_network_connect_db" ...
regards, tom lane
On Sat, Sep 6, 2014 at 6:05 PM, <chenchuanling@msn.com> wrote:
> The following bug has been logged on the website:
>
> Bug reference: 11365
> Logged by: chenchunling
> Email address: chenchuanling@msn.com
> PostgreSQL version: 9.3.5
> Operating system: centos6.3
> Description:
>
> Centos 6.3 integrated 8.4.11 version no problem,but upgrade to version
> 9.3.5
> apache cgi connection denied.Must be set: setenforce 0, such ability can
> be.
>
> selinux log:
> Sep 6 20:39:55 test kernel: type=1400 audit(1410050395.142:792): avc:
> denied { connectto } for pid=9559 comm="servergi"
> path="/tmp/.s.PGSQL.5432"
> scontext=unconfined_u:system_r:httpd_sys_script_t:s0
> tcontext=unconfined_u:system_r:initrc_t:s0 tclass=unix_stream_socket
> Sep 6 20:39:55 test kernel: type=1400 audit(1410050395.144:793): avc:
> denied { connectto } for pid=9559 comm="servergi"
> path="/tmp/.s.PGSQL.5432"
> scontext=unconfined_u:system_r:httpd_sys_script_t:s0
> tcontext=unconfined_u:system_r:initrc_t:s0 tclass=unix_stream_socket
>
In addition to Tom's comments, you could try specifying "localhost" so that
it connects over TCP rather than linux sockets.
There are all kinds of things that go wrong with unix sockets. Packagers
put the sockets in weird places. Services run with private temp files that
mask the real socket directory with something else.
Cheers,
Jeff
On 9/7/2014 9:36 AM, Tom Lane wrote: > That's not something the PG community can do anything about. If there's a > bug in the SELinux policy for apache, you need to complain to Red Hat to > get it fixed. > > I suspect though that if you dig a little bit, you will find that this > case has been foreseen, and there's a SELinux policy boolean that you > are supposed to set to allow apache processes to do database access. > A quick browse in the output of "semanage boolean -l" suggests that > "allow_user_postgresql_connect" might be the right thing, or maybe > "httpd_can_network_connect_db" ... the PGDG packagers probably should include some level of database selinux policy settings. maybe a special RPM that sets the apache database policy or something. -- john r pierce 37N 122W somewhere on the middle of the left coast
On 09/07/2014 06:22 PM, John R Pierce wrote: > On 9/7/2014 9:36 AM, Tom Lane wrote: >> That's not something the PG community can do anything about. If there's a >> bug in the SELinux policy for apache, you need to complain to Red Hat to >> get it fixed. >> >> I suspect though that if you dig a little bit, you will find that this >> case has been foreseen, and there's a SELinux policy boolean that you >> are supposed to set to allow apache processes to do database access. >> A quick browse in the output of "semanage boolean -l" suggests that >> "allow_user_postgresql_connect" might be the right thing, or maybe >> "httpd_can_network_connect_db" ... > > the PGDG packagers probably should include some level of database > selinux policy settings. maybe a special RPM that sets the apache > database policy or something. "Some special RPM" to do what exactly? Just because someone has PostgreSQL and Apache installed on their system doesn't mean they wanted httpd to be able to try to connect to their MySQL server on another machine in the network. Precisely that is what httpd_can_network_connect_db would allow (as a side effect). So please be more precise in what exactly that special RPM should set or enable. Regards, Jan -- Jan Wieck Senior Software Engineer http://slony.info
On 9/7/2014 10:02 PM, Jan Wieck wrote: >> the PGDG packagers probably should include some level of database >> selinux policy settings. maybe a special RPM that sets the apache >> database policy or something. > I probably should have said 'could' instead of 'probably should'. > "Some special RPM" to do what exactly? Just because someone has > PostgreSQL and Apache installed on their system doesn't mean they > wanted httpd to be able to try to connect to their MySQL server on > another machine in the network. Precisely that is what > httpd_can_network_connect_db would allow (as a side effect). > > So please be more precise in what exactly that special RPM should set > or enable. this RPM would be called something like postgresqlXY-apache-selinuxpolicy, and if installed, it would add the selinux policy that allows apache to connect to postgres version X.Y as installed from the same repository. if uninstalled, it would remove that policy. -- john r pierce 37N 122W somewhere on the middle of the left coast
John R Pierce <pierce@hogranch.com> writes:
> On 9/7/2014 10:02 PM, Jan Wieck wrote:
>> So please be more precise in what exactly that special RPM should set
>> or enable.
> this RPM would be called something like
> postgresqlXY-apache-selinuxpolicy, and if installed, it would add the
> selinux policy that allows apache to connect to postgres version X.Y as
> installed from the same repository. if uninstalled, it would remove
> that policy.
Hm ... would that not be in direct conflict with existing policy
variables?
I don't actually know a lot about what the standard Red Hat selinux
policy does in this area. If it were seriously broken, I'd probably
have heard more about it during the years I worked there. Not that
that's much of an argument, but it's some evidence for "there's no
fire here, only smoke". Anyway, I remain of the opinion that it'd
be best to press Red Hat's selinux people to fix/clarify/document
their policy's behavior for apache-to-database connections. Trying
to override the system policy with drive-by updates seems like a recipe
for disaster.
regards, tom lane
On 9/7/2014 11:24 PM, Tom Lane wrote: > Hm ... would that not be in direct conflict with existing policy > variables? good questions, and I'm not versed enough in the specifics to be able to answer. indeed, I have a rather shaky and sketchy understanding of the details of selinux... in my development lab environment, too often the first problem its caused, I've had to shut it off so my developers could get their jobs done. our software is only used inhouse, and manufacturing operations has not been remotely interested in dealing with selinux. Even if I carefully supported it with my group's stuff, they'd still be shutting it off for other reasons, beyond my control. > I don't actually know a lot about what the standard Red Hat selinux > policy does in this area. If it were seriously broken, I'd probably > have heard more about it during the years I worked there. Not that > that's much of an argument, but it's some evidence for "there's no > fire here, only smoke". Anyway, I remain of the opinion that it'd > be best to press Red Hat's selinux people to fix/clarify/document > their policy's behavior for apache-to-database connections. Trying > to override the system policy with drive-by updates seems like a recipe > for disaster. presumably other add-on packages need specific policies for themselves to operate in a selinux environment? I wonder how they do this. I'm envisioning this policy we add as something that doesn't conflict with existing policies, just adds the minimal magic to make it play nicely. -- john r pierce 37N 122W somewhere on the middle of the left coast