Bug 802570

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.

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.

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.

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.

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.

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?

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.

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!

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?

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.org so we can discuss further.

(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.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.

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.

(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.

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.

(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.

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.

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.

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.

Lots more reading for those interested:

http://unix.stackexchange.com/questions/82329/how-does-umask-affect-acls
http://serverfault.com/questions/352783/why-does-chmod1-on-the-group-affect-the-acl-mask/352915#352915

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

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.

what is the solution for this in 2018?  The last commentor mentioned "create" but that takes care of files inside not the actual /var/log/httpd directory which needs 750 and speciffic group left alone during upgrades. Do we need to do dirty hacks or there is an elegant way that works?

Comment 20 looks like a good method, I didn't know that ACLs were reset on updates when discussed this before.  Adding an "ExecStartPre=/bin/chgrp ... /var/log/httpd" or similar as a systemd drop-in could also work I think (RHEL7 only obviously).  Logging to somewhere other than /var/log/httpd also works and is the most obvious solution (you'll need SELinux policy too).

Thanks Joe
it wipes only the acl mask which makes sense because "chmod 700" should be strong enough so we could trust it always. In that case setting back just the acl mask should be sufficient (of course if we use ACLs for this in the first place. 

in rhel6 we can add chmod/chgrp/setfacl to postrotate section in logrotate.d/httpd or use mentioned in comment 20 package. So we have to use hacks after all. 

The funny part is that /etc/httpd is changed to 755 after upgrade. It is like redhat is worried about log files (700) more than config files.