Bug 1399501

Which version webalizer package did you use?

It is webalizer-2.23_08-1.el7

See bug #1382785 under webalizer.  Obviously some better coordination between webalizer and selinux-policy support teams needed.  The obvious lack of such would explain why this particular problem has been around for years..

On my current f25 system  I don't see any allow rules at all for webalizer_rw_content_t, which as near as I can tell is only assigned to directory /var/www/usage and files/directories below that.   This is data intended to be served by apache httpd, so obviously httpd is going to require access, and possibly others that might be appropriate for /var/www data as well.   Those problems wouldn't have been reported because the only way currently to get webalizer running with selinux was to change /var/www/usage(/.*)? files to some other context before webalizer would even start from cron, so that change would have occurred before httpd had any data to serve. I know the webalizer web pages work with httpd plus from the webalizer_t domain if you manually assign /var/www/usage(/.*)? to httpd_sys_content_t, so those definitions are certainly sufficient although some of those might not be necessary.

See also the suggestion that there needs to be a file context rule for /etc/webalizer/(.+)  to assign webalizer_etc_t to files under the directory /etc/webalizer (but not the directory itself) to handle suggested customization practices for multiple webalizer runs under a single cron script.

I had naturally assumed (from 30+ years of mainframe experience including RACF) that surely the SELinux definitions relating to webalizer would either be supplied or driven from the webalizer side or at least done with their knowledge and input, but I think I'm beginning to grasp that at this stage it may still be selinux folks looking from the outside, making best guesses from external behavior what it may take for the application to work and writing all the definitions; and the webalizer folks don't even know they need to talk with you when a problem is encountered that is really an SELinux issue. 

From past experience, the webalizer-selinux issue with /var/www/usage was particulary insidious because webalizer first checked whether it would have write access (a question selinux-policy apparently allowed it to ask) and then baled out with an error without ever trying to write, so by default there was never any se alert, only an application error. and the problem always got reported as a webalizer issue.

Hi, 
What I can add to webalizer.spec ? 
I ** don't want understand how selinux works ** , I just want that you list me what we need to run on webalizer.spec: 

semanage fcontext -a -t webalizer_etc_t  '/etc/webalizer/(.+)'
restorecon -R -v /etc/webalizer/*

anything else ? please just send shells scripts, please .

Sergio's Comment 5 comes from the context of webalizer bug #1382785  I'm the one who, as an affected user not a developer, tried to cross reference these two bugs together since they appear to be different parts of the same elephant.  My knowledge of what works as a circumvention comes from from my experience as a webalizer user and user of SELinux running with SELinux enabled.  I have no idea how cross-package issues are intended to be handled in the development arena when SELinux is involved, or what falls under the responsibility of those doing application package support versus those in SELinux support, or what is appropriate to include in an application package rpm spec file, or how to effect permanent changes in the selinux-policy package itself.

I am at this point inclined to guess/suspect that SELinux policy and SELinux file context "adjustments" may not be appropriate things to include in the webalizer package .spec file, but may more appropriately belong in selinux-policy package updates.

If that IS NOT correct, then webalizer support needs to be advised what they need to change in their package to correct their SELinux problem since they do not understand selinux.

If that IS correct, then selinux-policy needs to be updated to resolve these issues for a "permanent" fix of these webalizer SELinux issues, and the webalizer bug just needs to reference this bug and to indicate what commands can be used to provide a temporary manual circumvention until it is resolved by a future update to selinux-policy (or should that be selinux-policy-targeted -- not sure how all these selinux packages interrelate).

If people working with application package development have no understanding of how selinux issues can affect their package, or even who to communicate with to find how to resolve such issues, that is a problem.

(In reply to Joel C Ewing from comment #6)
OK , maybe Selinux team can help us , I suspect that webalizer problem also affect Fedora packages not just RHEL7 . The problem here maybe is that webalizer is not one RHEL package but one EPEL package , which is maintain by community of Fedora packagers, is not part of RHEL7 packages (IIRC is part of RHEL6).  
I disable selinux in all my machines, so it is hard to me test it , but I'd like support it, also may others distributions doesn't use selinux so I don't have any example ...

Definitely affects Fedora systems and packages.  I am a Fedora user, not RHEL, currently on f25 and the problems under discussion have been around at least since f19.  

I understand there is a reluctance to embrace SELinux by long-term users of Linux -- my own son has been a Unix Sysadmin for several decades and has yet to enable selinux on his own home servers because he doesn't feel he has time to deal with any issues that change might cause.  

I on the other hand, having come from an IBM mainframe System Programmer and Security Administrator perspective, have used various flavors of Linux on my home machines for personal use for over 15 years, and finally settled on the Fedora distro precisely because it had SELinux.  As a mainframe security administrator, SELinux was appealing because it had the potential to overcome some of the more serious deficiencies of  Unix security, and because it is built around many concepts that have counterparts in the mainframe security world.

This bugzilla was triaged as "WONTFIX" by the SELinux team, due to third-party software component which can be fixed by component maintainer. To take advantage of Mandatory Access Control mechanism provided by SELinux, you (component maintainer) can ship custom SELinux policy as a subpackage of  the affected component. As a starting point you can use policy provided by selinux-policy package. For more details  about the custom product policy, please follow the https://fedoraproject.org/wiki/SELinux/IndependentPolicy guideline.

Lukas Vrabec, Could you help ?  I won't fix it , because I don't user selinux neither have time to learn it .

duplicate is earlier bug

*** This bug has been marked as a duplicate of bug 1382785 ***