> Date: Tuesday, August 11, 2015 12:59:58 -0400
> From: m.roth@xxxxxxxxx
>
> Richard wrote:
>>> From: m.roth@xxxxxxxxx
> <snip>
>>> Anyway, starting late last week, we found issues - as in, its
>>> process, which runs under, and is started by, apache, was
>>> suddenly pegging a CPU or so. Trying to stop httpd, that
>>> worked... but this idiot process never did (and it's ugly to
>>> clean up after).
>>>
>>> What we just this morning found out to be the problem is that
>>> some package seems to change the permissions on /var/log/httpd
>>> to 700 from 770. The result was that this ...thing... couldn't
>>> write to its own logs, running as apache:root, while
>>> /var/log/httpd was root:root.
>>>
>>> I just did rpm -q httpd --scripts, and that doesn't show
>>> anything, so as I don't know what package did it.... If anyone
>>> knows, I'd like to know.
>>
>> I didn't try poking at the rpm too much, but just checked and
>> found that the httpd-2.2.15-45 rpm, that's part of the (regular)
>> 6.7 update, will change the permissions on the /var/log/httpd
>> directory (but not the files in it) to 700 and the ownership
>> (again, of the directory, not the included files) to root.root
>> from whatever you may have set them to. Those are the same
>> ownerships/permissions that are the default in 6.6.
>
> Really! Ok, how did you see that? When I ran rpm -q httpd
> --scripts, I got preinstall scriptlet (using /bin/sh):
># Add the "apache" user
> getent group apache >/dev/null || groupadd -g 48 -r apache
> getent passwd apache >/dev/null || \
> useradd -r -u 48 -g apache -s /sbin/nologin \
> -d /var/www -c "Apache" apache
> exit 0
> postinstall scriptlet (using /bin/sh):
># Register the httpd service
> /sbin/chkconfig --add httpd
> /sbin/chkconfig --add htcacheclean
> preuninstall scriptlet (using /bin/sh):
> if [ $1 = 0 ]; then
> /sbin/service httpd stop > /dev/null 2>&1
> /sbin/chkconfig --del httpd
> /sbin/service htcacheclean stop > /dev/null 2>&1
> /sbin/chkconfig --del htcacheclean
> fi
> posttrans scriptlet (using /bin/sh):
> test -f /etc/sysconfig/httpd-disable-posttrans || \
> /sbin/service httpd condrestart >/dev/null 2>&1 || :
>
> And there's no reference to /var/log/httpd.
>>
>> I.e., it appears that someone/thing modified the /var/log/httpd
>> directory permissions and ownerships from the default and the
>> updated httpd put them back.
>>
>> Isn't there a bit of a security issue in your (modified) setup
>> with those files being able to be written to by the apache user?
>
> So, since I haven't yet found where /var/log/httpd is created,
> what would a default package make the ownership of the directory?
> Does it expect it to be apache:root?
>
> Or does it expect that httpd run as apache:apache, and then
> /var/log/httpd should be apache:apache?
>
> Certainly, httpd shouldn't be running as root....
>
> mark
I simply mucked with the permissions and ownerships of the
/var/log/httpd directory/files on a 6.7 system and then did "yum
reinstall" of the httpd-2.2.15-45 rpm that's part of 6.7 and noted
what happened. I happen to also have a 6.6 system and compared
things between the two, so can say that the 6.7 and 6.6
/var/log/httpd directory defaults are the same -- 700 / root.root.
The default is that httpd starts as root and then spawns its worker
tasks as the user set in the "User" directive in the httpd.conf.
I believe that the security view is that if there is a hole in httpd
(directly, or more likely a (php/perl/...) script that someone is
using) you don't want apache (or whatever user the httpd worker
tasks are running as) to have write access to anything. That's why
it is generally considered bad form to have documentroot
directories/files owned by "apache" (or writeable by the apache
group) in the default setup.
Given that, I found it slightly amusing that your "security tool",
seemingly running as "apache", had write access to (and ownership
control of?) the httpd log directory and files.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
