Directory and files in it are world readable. They should be rw only for apache user and ro only for apache group. Reproducible: Always
diff -u -b -B -r1.27 apache-2.eclass --- ../eclass/apache-2.eclass 5 Mar 2012 08:20:52 -0000 1.27 +++ ../eclass/apache-2.eclass 29 Mar 2012 13:12:33 -0000 @@ -539,7 +539,7 @@ for i in /var/lib/dav /var/log/apache2 /var/cache/apache2 ; do keepdir ${i} fowners apache:apache ${i} - fperms 0755 ${i} + fperms 0750 ${i} done } Does that adequately fix it?
Yes.. new directories (e.G. /var/log/apache2) get perm 750, existing directories permissions stay the same as before. Is this a 'desired behaviour' of portage fperms helper-script?
Created attachment 307099 [details, diff] apache-2.eclass.patch
ah.. fperms is called in src_install and prepends ${D} by default. Added a small pkg_postinst routine in my patch to fix existing dirs. @Patrick Do you think this will break a thing or two somewhere or can we apply it to portage? Kind Regards
+ 29 Mar 2012; Patrick Lauer <patrick@gentoo.org> apache-2.eclass: + Sanitizing directory permissions #398899
Sorry, but this is not a solution at all, it breaks existing installations. I have various user-dirs in /var/log/apache2 and thus the x-flag for all on it. This now breaks everytime apache get's re-merged and with its current implementation there's no way for me to prevent this except maintaining my own local apache ebuild and eclass. It's okay to set the default to 0750, but when the user sets something otherwise, it shouldn't be enforced by a re-installation.
It sounds like chmod was used, try fowners and in src_install and the user permissions should be kept actually. That's what I do in BIND.
As nobody seems to care, I'll undo this now. It breaks for me every time I update my apache servers. If anyone thinks its still necessary to fix old installations, I'd propose echoing a warning. But messing with user-set permissions is no option.
If anyone has an idea how to solve this while making everyone happy, please speak up.
> I'd propose echoing a warning. But messing with user-set permissions is no option. That's sounds like a reasonable approach. Just check whether directory is world accessible and issue warning in this case.
(no clue why proxy-maint is in CC, removing)