Bug 802570 - Update of httpd package destroys permissions on /var/log/httpd/.
Update of httpd package destroys permissions on /var/log/httpd/.
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: httpd (Show other bugs)
5.9
All Linux
unspecified Severity low
: rc
: ---
Assigned To: Joe Orton
BaseOS QE Security Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-12 18:33 EDT by kop
Modified: 2015-08-26 12:46 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-13 17:39:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description kop 2012-03-12 18:33:41 EDT
Description of problem:

Upgrading the http package erases any changes made to the ownership and permissions of /var/log/httpd/ and it's content.    This makes it difficult
to grant non-root access (read-only or otherwise) to the webserver logs.

It is often desirable to allow various users and programs access to the webserver logs for analysis or other purposes.

Version-Release number of selected component (if applicable):

Tested on upgrade of 5.7 to 5.8.

How reproducible:

Very.

Steps to Reproduce:
1.  Install 5.7
2.  Allow the webmaster group to see the logs:

groupadd webmaster
chgrp -R webmaster /var/log/httpd
chmod -R g+r /var/log/httpd
chmod g+xs /var/log/httpd

3. Upgrade to 5.8.
  
Actual results:

/var/log/httpd/{.,*} reverts to root:root 0700

Expected results:

The the changes made by the sysadm to ownership and permissions on logs be left unchanged by the packaging system.

Additional info:

This is something of a policy issue and likely applies to logs created by other packages as well.  I believe but have not confirmed that the problem exists in RHEL 6 as well and that it is intrinsic to rpm and the current packaging policy; you may wish to re-classify the bug.  Since the issue affects policy you may not wish to fix it in 5 or 6, but it would be nice to see it fixed in future releases.

The httpd.spec file from httpd-2.2.15-15.el6_2.1.src.rpm (from RHEL6)
has a %file section which contains:

  %attr(0700,root,root) %dir %{_localstatedir}/log/httpd

I strongly suspect that RHEL 6 has the same problem.  (The RHEL5 spec file has the very same line in it's %file section, IIRC.)


The problem can be worked around in two fashions:

Apache (and logrotate and who knows what else) can be reconfigured to log to a different directory.  This is somewhat obtuse and non-standard.

ACLs can be used instead of traditional Unix permissions.  This is also somewhat obtuse, since ACLs aren't listed in the usual "ls -lh" it's non-obvious what's going on.  And this works only incidentally, because rpm does not happen to concern itself with ACLs. 


Putting the log directory in a %config section instead of a %file section in the rpm spec file may or may not be an appropriate solution.
Comment 1 kop 2012-03-13 10:36:52 EDT
I believe the original report is wrong in that the files within /var/log/httpd/ are not changed upon upgrade of the httpd package.  The remainder of the report is unaffected.
Comment 2 Joe Orton 2012-03-13 17:39:05 EDT
Thanks for contacting us.

The behaviour w.r.t. directory permissions is, as you imply, normal policy for RPM; the package is working as intended.  So this is not really a bug; there is nothing we we can change in httpd package itself here which will make any difference.

Using ACLs seems like a very reasonable way to get the behaviour you require, I know folks use that trick in similar circumstances with other packages and I'm not aware of any drawbacks.  

I'm going to close out this bug, please feel free to contact Red Hat Support who may be able to come up with other appropriate solutions.
Comment 3 kop 2012-03-14 11:54:47 EDT
I understand that the package is operating as designed.  I question the design. It would be nice to know the justification for restricting the ways in which sysadmins can grant permissions to logs.
Comment 4 Drew Northup 2013-10-24 17:35:36 EDT
If this wasn't a design error somewhere it wouldn't blow away either group overrides applied by the sysadmin nor filesystem ACLs applied by the sysadmin. I've been around long enough to know that if you cannot control the security groups granted permission to something AND HAVE THOSE CHANGES STICK then it is a security bug.
I don't care if the fix is a patch to the HTTPd package or a fix to RPM itself, but this is a problem that must be fixed before I'll take much of anything RedHat says about security seriously.
I sound angry because I am. FIX IT ALREADY. This problem also exists in RHEL6, and probably will in the RHEL7 beta. If using Ubuntu as a server wasn't such a dreadful problem with respect to outside vendor support and getting support from the people who originally wrote software RedHat would loose more customers than it does due to stupid problems like this.
Comment 5 kop 2013-10-24 20:30:21 EDT
What is disappointing is that up until this point I have always found
RedHat to be a very responsive company.  Their response in this case
looks like bureaucracy ossification has set in.  Whether this is due
to the way employees are evaluated (number of bugs closed) or an
unwillingness to interrupt people who know what they're doing, or
what, is hard to say.  I can only hope it's an isolated incident.

Fortunately the work-around is easy.  Don't store the website in the
default RedHat expected location and don't store the logs in the
expected location.  This is not as heinous as it sounds since Apache
must be configured anyway and it's simple enough to alter only the
last component of the paths resulting in paths that are reasonably
discoverable to a sysadm.

If you're really interested in getting this fixed I suspect that the
best approach is to work with the Fedora maintainers.  Once they make
the appropriate change I expect it will be easier to push the change
downstream to RedHat.
Comment 6 Hernan 2014-04-23 15:02:27 EDT
I totally agree with the OP. This behaviour sees designed for getting users mad.

I've experienced the same frustration with nginx in Fedora 19 http://forums.fedoraforum.org/showthread.php?t=298389

Permission 0700? Logs can only be read by the web user (httpd or nginx)? And this is forced in every update, not only installation? Very irritating.

What is the rationale

Come on, people, make it 0750  and/or stop modifying it in the updates.

> Using ACLs seems like a very reasonable way to get the behaviour you require, I know folks use that trick in similar circumstances with other packages and I'm not aware of any drawbacks

I don't use ACL and I don't want to. Why on earth would we need a TRICK to doing something as standard and reasonable as READING THE FUCKING WEB LOGS?
Comment 7 kop 2014-04-23 15:19:47 EDT
If RedHat is broken my thought is to lobby the Fedora maintainers and hope that sanity leaks back into RH.

While you're at it, I suspect that the rpm package may also be frobbing permissions on /var/www/http/, with unhappiness similar to that reported in this bug.  However I've not confirmed this.

I've given up on working with RH.  It's a shame.  I use a non-standard log location.
Comment 8 Joe Orton 2014-04-23 15:51:47 EDT
If anybody has a workable alternative to the status quo, I'm all ears.

I don't really have much to add beyond what I said in comment 2.  There is no conspiracy to annoy users, the behaviour here is a natural result of perfectly normal RPM packaging and it will be exactly the same across many packages in the distro.

And the Fedora httpd maintainers are exactly the same people as the RHEL httpd maintainers!
Comment 9 kop 2014-04-23 16:10:13 EDT
What you need is a policy decision.  RH has rightly decided that configuration files belong to the system administrator -- both the meta-information (permissions etc) and the content.  RH has wrongly decided that /var/log/httpd/ (and perhaps other directories like /var/www/http/) belong to the package manager, in the same sense that, say, system binares do.  This seems perverse since the sysadmin has control over where log files reside.  (And where document root lives etc.)

All this does is encourage sysadmins to put stuff in non-standard directories to keep from being bitten by the package manager.

There's good reason to put binaries under the purview of the package manager.  I've heard no agument for why RPM ownership of log directories (etc.) is a good idea.  There are valid reasons why a sysadmin would want control over these, so why the dis-connect with RPM policy?
Comment 10 Joe Orton 2014-04-24 04:48:36 EDT
I'm reading a lot of abstract claims that Things Should Be Better here without a concrete proposal for how to actually make things "better".  Set against that we've offered a simple way to achieve desired results (ACLs) with the existing packages.

It's hard to justify investing a lot of RH engineering time in this issue.  If you can boil down your proposal to something more concrete then it'd be great if you can bring it along to devel@lists.fedoraproject.org so we can discuss further.
Comment 11 Drew Northup 2014-04-24 07:13:48 EDT
(In reply to Joe Orton from comment #10)
> I'm reading a lot of abstract claims that Things Should Be Better here
> without a concrete proposal for how to actually make things "better".  Set
> against that we've offered a simple way to achieve desired results (ACLs)
> with the existing packages.

Joe,
The proposed fix (ACLs), as I noted earlier (comment #4), DOES NOT WORK. Therefore, it is not a simple way to achieve the desired results.


> It's hard to justify investing a lot of RH engineering time in this issue. 
> If you can boil down your proposal to something more concrete then it'd be
> great if you can bring it along to devel@lists.fedoraproject.org so we can
> discuss further.

It seems that this kind of problem has been discussed already:
https://fedoraproject.org/wiki/PackagingDrafts/Logfiles

From my reading of what is on that page, this is due to a gross oversight in the design of RPM: One cannot specify to NOT apply %attr() on already existing log directories (or other already existing files, remembering that directories are just a special kind of file).
Therefore, it appears that RPM needs to have available a "%log" and "%log(noreplace)" pair of directives. Another possibility is that some sort of "(nochattr)" directive, available more broadly.

If we were to choose something more surgical, a %pre or %post script addition of   something like:

if [ ! -e %{_localstatedir}/log/httpd ]
    then mkdir -p %{_localstatedir}/log/httpd && \
         chmod 700 %{_localstatedir}/log/httpd && \
         chown root.root %{_localstatedir}/log/httpd;
fi;

and a change of the line in the %files section (diff -u form):

- %attr(0700,root,root) %dir %{_localstatedir}/log/httpd
+ %ghost %dir %{_localstatedir}/log/httpd

would hopefully do the job.
Comment 12 kop 2014-04-24 10:20:24 EDT
What's wrong with declaring the directories to be configuration "files" so that RPM leaves them alone when changed?  This suggestion was part of the initial bug report.
Comment 13 Drew Northup 2014-04-24 10:31:21 EDT
(In reply to kop from comment #12)
> What's wrong with declaring the directories to be configuration "files" so
> that RPM leaves them alone when changed?  This suggestion was part of the
> initial bug report.

As noted in https://fedoraproject.org/wiki/PackagingDrafts/Logfiles 
"cases C, F, G and H (various %config attributes) rename old logfiles to .rpmsave; since .rpmsave files will not be backup-ed by rpm, subsequent rpm -U ; rpm -e operations will cause loss of logfiles too[.]"
Only when %config and %ghost are combined is it presumed (in that draft) that the logs would be unperturbed. It appears to me that they did not test the case of a log directory being defined in the %files section, only testing regular files. That's where my suggestion comes from.

In any case, I don't know that %config(noreplace) actually overrides the application of %attr() directives. I don't see any reason to presume that it would.
Comment 14 kop 2014-04-24 10:52:17 EDT
I'm not trying to fix all the problems with RPM here, just trying to keep RPM from messing with the meta-information of the log directories.

Regards whether %config(noreplace) or %attr() has priority, I suppose the thing to do is try it.  Since the who point of %config is to keep rpm from changing a config file I'd presume that %config would have priority.   But rpm has evolved quite a bit (and become increasingly undocumented, last I paid attenion) since the days when I was intimate with it so this is a valid concern.  All I recall is plain old %config, and it ment that once the files were installed they were subsequently untouched by RPM.
Comment 15 Drew Northup 2014-04-24 12:16:58 EDT
(In reply to kop from comment #14)

> Regards whether %config(noreplace) or %attr() has priority, I suppose the
> thing to do is try it.  Since the who point of %config is to keep rpm from
> changing a config file I'd presume that %config would have priority.   But
> rpm has evolved quite a bit (and become increasingly undocumented, last I
> paid attenion) since the days when I was intimate with it so this is a valid
> concern.  All I recall is plain old %config, and it ment that once the files
> were installed they were subsequently untouched by RPM.

So, I built one as you suggested, and then updated to it.

Before:
[root@drew-northup log]# ls -lad h*
drwx------ 2 root root 4096 Mar 26 08:49 httpd
[root@drew-northup log]# chgrp users httpd
[root@drew-northup log]# ls -lad h*
drwx------ 2 root users 4096 Mar 26 08:49 httpd
[root@drew-northup log]# chmod 750 httpd
[root@drew-northup log]# ls -lad h*
drwxr-x--- 2 root users 4096 Mar 26 08:49 httpd

After:
[root@drew-northup log]# ls -lad h*
drwx------ 2 root root 4096 Apr 24 12:06 httpd

With a %files section containing this entry:
%attr(0700,root,root) %config(noreplace) %dir %{_localstatedir}/log/httpd

When I try my (somewhat more obtuse, I admit) fix, I have the following both before and after updating (I reset it before to be sure).
[root@drew-northup log]# chmod 750 httpd
[root@drew-northup log]# chgrp users httpd
[root@drew-northup log]# ls -lad h*
drwxr-x--- 2 root users 4096 Apr 24 12:06 httpd
[root@drew-northup log]# ls -lad h*
drwxr-x--- 2 root users 4096 Apr 24 12:06 httpd

It's a messy hack of a fix, but it did have the desired result.
Comment 16 Peter Ajamian 2014-04-24 22:28:39 EDT
Personally I'd rather not see %config used for log files, For one thing this would cause the directory to show up under rpm -qc httpd plus as others have states there is other config-specific behavior that is undesirable here.  I think that we're better off with the %ghost %post workaround and filing a feature request against rpm for this ability for log directories, probably just a (noreplace) (or maybe nochange would be better) option to %dir would do it.
Comment 17 kop 2014-04-25 07:26:00 EDT
I see having such directories as /var/log/httpd/ show up in `rpm -qc httpd` output as a feature not a bug.  How else are you going to ask rpm to list such directories?  Config files and directories, log files, log directories, such data directories as document root (/var/www/html) all fall into the same category -- things that should be installed, perhaps, but not subseqeuntly changed by RPM.

I am likewise not convinced that %config's renaming to add '.rpmsave' or '.rpmnew' is a bad thing, especially if rpm could be made to rename directories first.  Then when it goes to rename the log files it wouldn't, because they would no longer be in the specified directory.  I can't easily find any documenation so I can't tell if this really makes sense regards how rpm triggers "save" or "new".  In any case the point would be the same as when renameing regular config files with '.rpmnew' or '.rpmsave' suffixes, to set aside files when there are major changes in data structure.

Just because the directive is called %config is a historical accident.  When writing a spec file what's important is not the purpose of the filesystem object at runtime but how RPM intearcts with the filesystem object.
Comment 18 Mark A. Hershberger 2014-09-12 20:34:00 EDT
So, I just ran into this exact problem -- we have someone we want to run stats on the log files, so we made sure she could access them.

Then, this week, we upgraded httpd and her permissions stopped working.

I *tried* setfacl but it don't work.  The simplest way to demonstrate this is the following:

 ># setfacl -m m:rx,g:wiki:rx /var/log/httpd
 ># getfacl /var/log/httpd
  getfacl: Removing leading '/' from absolute path names
  # file: var/log/httpd
  # owner: root
  # group: root
  user::rwx
  group::---
  group:wiki:r-x
  mask::r-x
  other::---

 ># rpm --setperms httpd
 ># getfacl /var/log/httpd
  getfacl: Removing leading '/' from absolute path names
  # file: var/log/httpd
  # owner: root
  # group: root
  user::rwx
  group::---
  group:wiki:r-x               #effective:---
  mask::---
  other::---

 ># setfacl -m m:rx /var/log/httpd  
 ># getfacl /var/log/httpd
  getfacl: Removing leading '/' from absolute path names
  # file: var/log/httpd
  # owner: root
  # group: root
  user::rwx
  group::---
  group:wiki:r-x
  mask::r-x
  other::---

Doing an strace on rpm shows that it does "chmod 700 /var/log/httpd".  Replacing "rpm --setperms httpd" with "chmod 700 /var/log/httpd" gives the same result as that given above.

So, this really isn't rpm's fault.  It is chmod's.

Now, if only chmod left the ACL mask alone, the ACL solution would work.
Comment 20 Thomas Babut 2015-01-15 04:44:42 EST
We had the same problem and solved it with installing the package "yum-plugin-post-transaction-actions" and adding a script "/etc/yum/post-actions/httpd.action":

httpd*:update:chgrp devs /var/log/httpd && chmod g+rx /var/log/httpd
Comment 21 Steve Rogerson 2015-08-26 12:46:23 EDT
The ubuntu family solution to this is - essentially 

    create 640 root adm

in the logrotate for httpd. 

Which seems simple enough. In fact it's so simple I figure there has to a deep and meaningful reason why this isn't done, but it escapes me.

Note You need to log in before you can comment on or make changes to this bug.