Hi all,
It appears that on my nice little CentOS 5.3 machines Apache only allows me to store content in directories which are under /var/www/
For instance, putting content in /var/www/test and defining the following alias:
Alias /test /var/www/test
then accessing it under http://hostname/test works great.
Not copy that same content to /home/test, change the alias to:
Alias /test /home/test
and you get Error 403.
Any idea why that would be?
Never had this sort of trouble anywhere, including under CentOS 5.0 and 5.1
Thanks in advance for any and all help.
Boris.
Hi,
On Fri, Jul 31, 2009 at 12:17, Boris Epsteinborepstein@gmail.com wrote:
Any idea why that would be?
It's SELinux. Files exported by Apache must have context httpd_sys_content_t. You can use "ls -Z" to see the context of a certain file. You can use "chcon -R httpd_sys_content_t /home/test" to change the context of all the files in the /home/test directory, however that will not apply to new files created under that directory, in which case you have to add new rules using "semanage fcontext" (see the examples "man semanage" for help on how to do that).
In general I would advise you to try to adapt your application so that the files that need to be seen by Apache are under /var/www, if you have that flexibility it will be simpler and have less chance of breaking in the future.
HTH, Filipe
--On Friday, July 31, 2009 1:24 PM -0400 Filipe Brandenburger filbranden@gmail.com wrote:
In general I would advise you to try to adapt your application so that the files that need to be seen by Apache are under /var/www, if you have that flexibility it will be simpler and have less chance of breaking in the future.
IIRC, there's a policy and boolean to allow users to have web content in ~/public_html.
If one has stuff in other locations (say, /usr/share/someapp/webcontent or /opt/someapp/webcontent), one could use a loopback mount to attach it to a subdirectory of /var/www.
On Fri, Jul 31, 2009 at 12:24 PM, Filipe Brandenburger filbranden@gmail.com wrote:
Hi,
On Fri, Jul 31, 2009 at 12:17, Boris Epsteinborepstein@gmail.com wrote:
Any idea why that would be?
It's SELinux. Files exported by Apache must have context httpd_sys_content_t. You can use "ls -Z" to see the context of a certain file. You can use "chcon -R httpd_sys_content_t /home/test" to change the context of all the files in the /home/test directory, however that will not apply to new files created under that directory, in which case you have to add new rules using "semanage fcontext" (see the examples "man semanage" for help on how to do that).
In general I would advise you to try to adapt your application so that the files that need to be seen by Apache are under /var/www, if you have that flexibility it will be simpler and have less chance of breaking in the future.
HTH, Filipe _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I found an even simplier solution - disabled SELinux. I've got a firewall and that is plenty.
Thanks a lot, Filipe!
On Fri, Jul 31, 2009 at 12:35 PM, Boris Epsteinborepstein@gmail.com wrote:
I found an even simplier solution - disabled SELinux. I've got a firewall and that is plenty.
No. It's really not. If someone exploits apache, or php, they'll be coming in via port 80 or 443 which your firewall has helpfully allowed so that you can run your server. The vast majority of successful penetrations I've seen are of two types. Brute ssh attacks, and apache/php exloits. If you were running mod_security, that might be slightly more analogous to selinux. I really don't recommend that people disable selinux simply because they can't be bothered to learn it.
Real world reasons for selinux on web servers -> http://www.linuxjournal.com/article/9176
On Fri, Jul 31, 2009 at 12:50 PM, Jim Perrinjperrin@gmail.com wrote:
On Fri, Jul 31, 2009 at 12:35 PM, Boris Epsteinborepstein@gmail.com wrote:
I found an even simplier solution - disabled SELinux. I've got a firewall and that is plenty.
No. It's really not. If someone exploits apache, or php, they'll be coming in via port 80 or 443 which your firewall has helpfully allowed so that you can run your server. The vast majority of successful penetrations I've seen are of two types. Brute ssh attacks, and apache/php exloits. If you were running mod_security, that might be slightly more analogous to selinux. I really don't recommend that people disable selinux simply because they can't be bothered to learn it.
Real world reasons for selinux on web servers -> http://www.linuxjournal.com/article/9176
-- During times of universal deceit, telling the truth becomes a revolutionary act. George Orwell _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I am running mod_security and also if the intruder gets to the shell level they will be able to bypass the SELinux entirely. I believe in security too but security should not be crippling.
Boris.
--On Friday, July 31, 2009 2:07 PM -0400 Boris Epstein borepstein@gmail.com wrote:
I am running mod_security and also if the intruder gets to the shell level they will be able to bypass the SELinux entirely.
How? The selinux commands require root access. First you'd have to get a root escalation exploit to promote from user apache to root, and then disable selinux. The exploit in the linked article is stopped because it can't run the escalation program which was downloaded to /tmp.
I believe in security too but security should not be crippling.
Do you also disable iptables, because a firewall is too complicated to configure just to run an IP service?
SELinux is just another kind of firewall, but one between user/process/resource triplets. As with a good network firewall, it denies all by default and one selectively allows the triplets that make sense for one's application.
On Fri, Jul 31, 2009 at 1:07 PM, Boris Epsteinborepstein@gmail.com wrote:
I am running mod_security and also if the intruder gets to the shell level they will be able to bypass the SELinux entirely. I believe in security too but security should not be crippling.
Agreed, however your statement is contradictory. A person not versed in iptables would find the default firewall crippling when attempting to run apache. By your logic, they should disable the firewall?
Boris Epstein wrote:
I found an even simplier solution - disabled SELinux. I've got a firewall and that is plenty.
Wow, not sure I'd place all my faith in a firewall.
There is an SELinux tutorial on the Wiki that explicitly covers how to handle Apache serving content outside of DocumentRoot:
http://wiki.centos.org/HowTos/SELinux
Anyway, it's only one command to fix the issue - not exactly daunting.
On Fri, 31 Jul 2009, Ned Slider wrote:
Boris Epstein wrote:
I found an even simplier solution - disabled SELinux. I've got a firewall and that is plenty.
Wow, not sure I'd place all my faith in a firewall.
There is an SELinux tutorial on the Wiki that explicitly covers how to handle Apache serving content outside of DocumentRoot:
Is this why DBD::SQLite broke under mod_perl recently in CentOS?
I.e. Apache process is accessing an sqlite file that is outside the docroot. This is how it should be.
Conf perms (allow/deny) only secure what files you can access by calling them up with a uri mapping. They don't apply to what files a script or handler can access; any of these processes running as user apache can access any files that user could access on the system.
Unless selinux is interfereing. Is that what's going on?
Help?
Mark
--On Saturday, August 01, 2009 10:30 AM -0700 Mark Hedges hedges@scriptdolphin.com wrote:
I.e. Apache process is accessing an sqlite file that is outside the docroot. This is how it should be.
Don't use /var/www as your docroot. Use a subdirectory. Then you can put other files under /var/www that are not under the docroot.
Aside: Avoid editing httpd.conf if you can help it. A lot of customization can be accomplished by dropping a custom .conf file in /etc/httpd/conf.d. This makes upgrades a lot easier, in case the stock httpd.conf changes.
Hi,
On Sat, Aug 1, 2009 at 12:30, Mark Hedgeshedges@scriptdolphin.com wrote:
Is this why DBD::SQLite broke under mod_perl recently in CentOS?
It might or might not be... In order to be sure, you may check the audit logs at /var/log/audit/audit.log (make sure the "audit" RPM is installed and the "auditd" daemon is enabled and running), you might see SELinux messages in that file when some access is denied.
HTH, Filipe
Filipe Brandenburger wrote:
Hi,
On Sat, Aug 1, 2009 at 12:30, Mark Hedgeshedges@scriptdolphin.com wrote:
Is this why DBD::SQLite broke under mod_perl recently in CentOS?
It might or might not be... In order to be sure, you may check the audit logs at /var/log/audit/audit.log (make sure the "audit" RPM is installed and the "auditd" daemon is enabled and running), you might see SELinux messages in that file when some access is denied.
HTH, Filipe
Further to Filipe's advice, if you temporarily switch SELinux into permissive mode and stuff then works again, take that as a pretty good indication that it was indeed SELinux that was preventing it. At that point you know where to look to fix the problem.
The Wiki guide for SELinux has lots of information on troubleshooting SELinux issues:
On Sat, 1 Aug 2009, Ned Slider wrote:
Filipe Brandenburger wrote:
On Sat, Aug 1, 2009 at 12:30, Mark Hedgeshedges@scriptdolphin.com wrote:
Is this why DBD::SQLite broke under mod_perl recently in CentOS?
It might or might not be... In order to be sure, you may check the audit logs at /var/log/audit/audit.log (make sure the "audit" RPM is installed and the "auditd" daemon is enabled and running), you might see SELinux messages in that file when some access is denied.
Further to Filipe's advice, if you temporarily switch SELinux into permissive mode and stuff then works again, take that as a pretty good indication that it was indeed SELinux that was preventing it. At that point you know where to look to fix the problem.
No, this is not my problem anyway.
hedges@anubis:~$ sestatus SELinux status: disabled
With SELinux off, any script run by apache can access anything on the filesystem that can be read by the apache process user. Maybe that's not the best way to do it, but it confirms that SELinux is not causing DBD::MySQL to break under mod_perl in CentOS 5.3.
It looks like it was a buggy release in apr-util 1.2.7-7.el5_3.1 or httpd 2.2.3-22.el5.centos.2
Who packages httpd for Centos? Is there some way to contact a person to ask them about this?
I feel like it's pointless to ask why don't distributions upgrade within the minor revision number of the stable 2.2 series anyway. 2.2.3 is certainly not as "stable" as 2.2.11 and the API is supposed to be the same. Oh right the "big picture." :-(
Mark
Mark Hedges wrote:
With SELinux off, any script run by apache can access anything on the filesystem that can be read by the apache process user. Maybe that's not the best way to do it, but it confirms that SELinux is not causing DBD::MySQL to break under mod_perl in CentOS 5.3.
I recall a previous post from you mentioning breakage, but I don't recall seeing any log events(e.g. permission denied messages or error traces etc) that might point to where the issue is. Can you provide this to help diagnose the issue?
The original post I recall was this one: http://lists.centos.org/pipermail/centos/2009-August/079995.html
nate (All my systems ship with SELinux disabled)
On Thu, 6 Aug 2009, nate wrote:
With SELinux off, any script run by apache can access anything on the filesystem that can be read by the apache process user. Maybe that's not the best way to do it, but it confirms that SELinux is not causing DBD::MySQL to break under mod_perl in CentOS 5.3.
I recall a previous post from you mentioning breakage, but I don't recall seeing any log events(e.g. permission denied messages or error traces etc) that might point to where the issue is. Can you provide this to help diagnose the issue?
The original post I recall was this one: http://lists.centos.org/pipermail/centos/2009-August/079995.html
Sorry I changed the subject.
Here's what people have collected so far:
https://rt.cpan.org/Ticket/Display.html?id=47983
This is a message I posted when I signed up for the list, I thought it was ignored but it looks like it didn't post:
On Wed, 29 Jul 2009, Mark Hedges wrote:
On Thu, 23 Jul 2009, Fred Moyer wrote:
Looks like dev@httpd is aware of the issue and will be releasing a fix. Haven't tried 5.3 centos but this sounds like they shipped a version of apache that caused this.
http://www.mail-archive.com/dev@httpd.apache.org/msg44177.html
Hello, it seems like httpd-devel 2.2.3 was patched with a bug from an upstream version. DBD::SQLite no longer works under mod_perl2, generating an error which is "not an error" upon any attempt to select something. (The same selects all work in a command-line script.) (https://rt.cpan.org/Ticket/Display.html?id=47983)
I tried to sign up for a centos bug report username, but the signup form is buggy, the captcha never works....
Any chance someone can try to fix this?
Thanks! --mark--
Mark Hedges wrote:
Here's what people have collected so far:
https://rt.cpan.org/Ticket/Display.html?id=47983
This is a message I posted when I signed up for the list, I thought it was ignored but it looks like it didn't post:
I looked through it and wow it does seem like a fairly deep issue, reminds me of the problems I have when I need to ask for help often I don't get responses as they are deep as well.
I don't think I'm able to help on this one but am curious how much of the components your working with are built from outside sources? I get the impression that your using quite a few modules directly from CPAN, are you using sqlite and mod_perl stuff from outside CentOS as well?
nate
Hi,
On Thu, Aug 6, 2009 at 17:58, Mark Hedgeshedges@scriptdolphin.com wrote:
Who packages httpd for Centos? Is there some way to contact a person to ask them about this?
You can report problems on the CentOS bug tracker at: http://bugs.centos.org/
If the problem is reproducible in RHEL as well, you might as well report it directly at: https://bugzilla.redhat.com/
I feel like it's pointless to ask why don't distributions upgrade within the minor revision number of the stable 2.2 series anyway. 2.2.3 is certainly not as "stable" as 2.2.11 and the API is supposed to be the same. Oh right the "big picture." :-(
2.2.3 in CentOS/RHEL is not the same as 2.2.3 upstream... it's only the base release after which patches are applied. The name 2.2.3 is kept because potentially not all the upstream patches that went to 2.2.11 will go into CentOS/RHEL's 2.2.3, in theory only security updates are applied inside a minor OS release and RedHat might decide to skip some of the patches introduced between 2.2.3 and 2.2.11 if they believe they are not relevant to their product.
On Fri, Aug 7, 2009 at 00:48, Mark Hedgeshedges@scriptdolphin.com wrote:
Here's what people have collected so far: https://rt.cpan.org/Ticket/Display.html?id=47983
First: you still did not describe your problem on this mailing list, so it's really hard to help you with that.
Second: from that link it seems that you have installed Perl modules directly from CPAN. Is that true? If you did and your system broke, well, you got to keep the pieces... It's known that CPAN modules and RPM modules do not play together well and will tend to break in upgrades. I suggest you install a CentOS 5.3 machine from scratch and try to reproduce the problem there. If it still happens, then report it to CentOS's bug tracker and/or to the mailing list.
HTH, Filipe
You can report problems on the CentOS bug tracker at: http://bugs.centos.org/
Umm, as I said, I couldn't sign up to file a bug report. Nope, still broken.
APPLICATION ERROR #2800 Invalid form security token. Did you submit the form twice by accident?
If the problem is reproducible in RHEL as well, you might as well report it directly at: https://bugzilla.redhat.com/
I don't have an RHEL to test I use Debian at home, but thanks for the link, since it is the same source according to Johnny below.
I feel like it's pointless to ask why don't distributions upgrade within the minor revision number of the stable 2.2 series anyway. 2.2.3 is certainly not as "stable" as 2.2.11 and the API is supposed to be the same. Oh right the "big picture." :-(
2.2.3 in CentOS/RHEL is not the same as 2.2.3 upstream... it's only the base release after which patches are applied. The name 2.2.3 is kept because potentially not all the upstream patches that went to 2.2.11 will go into CentOS/RHEL's 2.2.3, in theory only security updates are applied inside a minor OS release and RedHat might decide to skip some of the patches introduced between 2.2.3 and 2.2.11 if they believe they are not relevant to their product.
Yeah it doesn't make sense to me why it's an advantage for RedHat to selectively backport patches instead of keeping up what the developers believe is a stable API for all callers. It's the same corporate cargo cult they were in when they made the mod_perl1 "compatibility" interface for Apache2... just made life harder for everyone in the end, if I'd wanted to use 1.3 handler API I would have installed 1.3... but that is ancient history.
Second: from that link it seems that you have installed Perl modules directly from CPAN. Is that true? If you did and your system broke, well, you got to keep the pieces... It's known that CPAN modules and RPM modules do not play together well and will tend to break in upgrades. I suggest you install a CentOS 5.3 machine from scratch and try to reproduce the problem there. If it still happens, then report it to CentOS's bug tracker and/or to the mailing list.
Yes I removed all of perl, made sure all libs were gone and started from scratch.
On Fri, 7 Aug 2009, nate wrote:
I don't think I'm able to help on this one but am curious how much of the components your working with are built from outside sources? I get the impression that your using quite a few modules directly from CPAN, are you using sqlite and mod_perl stuff from outside CentOS as well?
I use httpd, httpd-devel, sqlite, sqlite-devel, mod_perl, mod_perl-devel, apr etc. from CentOS.
DBD::SQLite is not available in yum so I make it with CPAN.
libapreq2 (Apache2::Cookie/Apache2::Request) is not available in yum and does not run the tests right with the CPAN installer as root so I make it from source.
On Fri, 7 Aug 2009, Johnny Hughes wrote:
Well ... here is what I can tell you:
http://www.redhat.com/security/updates/backporting/?sc_cid=3093
They do roll in bug fixes. I know it can be frustrating (it is for me to and I build this stuff) ...
WRT the httpd package ... if you look at the RHEL and CentOS httpd SRPMs you will see that the change in the spec file is cosmetic and only controls CentOS being displayed instead of Red Hat as required by their trademark restrictions.
Excellent info I will swim upstream thank you.
Mark
Yeah it doesn't make sense to me why it's an advantage for RedHat to selectively backport patches instead of keeping up what the developers believe is a stable API for all callers. It's the same corporate cargo cult they were in when they made the mod_perl1 "compatibility" interface for Apache2... just made life harder for everyone in the end, if I'd wanted to use 1.3 handler API I would have installed 1.3... but that is ancient history.
Oh they give the 2.0.43 as an excuse at http://www.redhat.com/security/updates/backporting/?sc_cid=3093 .. but what actually makes code stable is fixing the code, it's bollocks.
Mark
Mark Hedges wrote:
You can report problems on the CentOS bug tracker at: http://bugs.centos.org/
Umm, as I said, I couldn't sign up to file a bug report. Nope, still broken.
APPLICATION ERROR #2800 Invalid form security token. Did you submit the form twice by accident?
I am not sure how you are applying for your login.
I was able to use IE7 and IE8 on Windows XP, Firefox on Windows, and Firefox on Linux to obtain a login.
<snip>
On Sat, 2009-08-08 at 05:59 -0500, Johnny Hughes wrote:
Mark Hedges wrote:
You can report problems on the CentOS bug tracker at: http://bugs.centos.org/
Umm, as I said, I couldn't sign up to file a bug report. Nope, still broken.
APPLICATION ERROR #2800 Invalid form security token. Did you submit the form twice by accident?
I am not sure how you are applying for your login.
I was able to use IE7 and IE8 on Windows XP, Firefox on Windows, and Firefox on Linux to obtain a login.
<snip>
--- To add to that it does give an error at times on logging in. Does not matter what os/browser. Also on account creation.
John
Hi,
On Fri, Aug 7, 2009 at 23:00, Mark Hedgeshedges@scriptdolphin.com wrote:
DBD::SQLite is not available in yum so I make it with CPAN.
libapreq2 (Apache2::Cookie/Apache2::Request) is not available in yum and does not run the tests right with the CPAN installer as root so I make it from source.
I believe both perl-DBD-SQLite 1.14 and libapreq2 2.09 are available from EPEL.
perl-DBD-SQLite 1.25 is available from RPMforge.
For more information on how to use these repositories: http://wiki.centos.org/AdditionalResources/Repositories
I would not advise to mix those two repositories, and whichever one you use, I would advise you to use the yum "priorities" plugin to avoid having them upgrade packages of your base CentOS setup.
You may also join the mailing lists of those repositories to request the addition of new packages or upgrades of some of them to specific versions. In that case I would recommend the RPMforge repository, IMO their work with the Perl packages is very good.
HTH, Filipe
Mark Hedges wrote:
On Sat, 1 Aug 2009, Ned Slider wrote:
Filipe Brandenburger wrote:
On Sat, Aug 1, 2009 at 12:30, Mark Hedgeshedges@scriptdolphin.com wrote:
Is this why DBD::SQLite broke under mod_perl recently in CentOS?
It might or might not be... In order to be sure, you may check the audit logs at /var/log/audit/audit.log (make sure the "audit" RPM is installed and the "auditd" daemon is enabled and running), you might see SELinux messages in that file when some access is denied.
Further to Filipe's advice, if you temporarily switch SELinux into permissive mode and stuff then works again, take that as a pretty good indication that it was indeed SELinux that was preventing it. At that point you know where to look to fix the problem.
No, this is not my problem anyway.
hedges@anubis:~$ sestatus SELinux status: disabled
With SELinux off, any script run by apache can access anything on the filesystem that can be read by the apache process user. Maybe that's not the best way to do it, but it confirms that SELinux is not causing DBD::MySQL to break under mod_perl in CentOS 5.3.
It looks like it was a buggy release in apr-util 1.2.7-7.el5_3.1 or httpd 2.2.3-22.el5.centos.2
Who packages httpd for Centos? Is there some way to contact a person to ask them about this?
I feel like it's pointless to ask why don't distributions upgrade within the minor revision number of the stable 2.2 series anyway. 2.2.3 is certainly not as "stable" as 2.2.11 and the API is supposed to be the same. Oh right the "big picture." :-(
Well ... here is what I can tell you:
http://www.redhat.com/security/updates/backporting/?sc_cid=3093
They do roll in bug fixes. I know it can be frustrating (it is for me to and I build this stuff) ...
WRT the httpd package ... if you look at the RHEL and CentOS httpd SRPMs you will see that the change in the spec file is cosmetic and only controls CentOS being displayed instead of Red Hat as required by their trademark restrictions.
sounds like current default apache security
near the begining you of httpd.conf you will find
<Directory /> Options FollowSymLinks AllowOverride None </Directory>
<Directory "/var/www/html"> Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory>
This effectively blocks you from sharing any directory (even aliased ones) unless the actual directory (no symlinks or aliases) is under /var/www.
to add in exceptions put this under your alias statement.
Alias /test /home/test <Directory /home/test> Order allow,deny Allow from all </Directory>
________________________________
From: centos-bounces@centos.org on behalf of Boris Epstein Sent: Fri 7/31/2009 9:17 AM To: centos@centos.org Subject: [CentOS] Apache not liking directories outside of /var/www
Hi all,
It appears that on my nice little CentOS 5.3 machines Apache only allows me to store content in directories which are under /var/www/
For instance, putting content in /var/www/test and defining the following alias:
Alias /test /var/www/test
then accessing it under http://hostname/test works great.
Not copy that same content to /home/test, change the alias to:
Alias /test /home/test
and you get Error 403.
Any idea why that would be?
Never had this sort of trouble anywhere, including under CentOS 5.0 and 5.1
Thanks in advance for any and all help.
Boris. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Boris Epstein -
Filipe Brandenburger -
jacob＠aers.ca -
Jim Perrin -
Johnny Hughes -
JohnS -
Kenneth Porter -
Mark Hedges -
nate -
Ned Slider