> The ability to relocate *all* of the executables in > /usr/share/shorewall/ was released in 4.4.19. It's now up to the > distributions to make use of that ability. > The problem is not because of this file's location, the problem is with 1) the wrong security context defined and assigned to this file (SELinux policy bug); and/or 2) shorewall security domain (shorewall_t) has not been granted the necessary privileges to access/execute its own files (getparams in this case), hence the error (SELinux policy bug).
Either way - it is a policy bug, whichever way it is looked at. I could place getparams in /root for what I care, provided the right security policy is compiled and installed on that machine, I will not get an error and shorewall will be running properly! The same thing happened with ipset more than a year ago - shorewall could not execute properly because I was running ipset within /etc/shorewall/init and than triggered a security error preventing shorewall from starting. Why? Because some bright spark at Fedora thought that ipset does not form any part of the Netfilter group of domains and therefore should not be allowed to execute within the shorewall_t security domain. I took them months to correct that. The same is happening with getparams and I am just wondering how many months will pass before someone at Fedora decides to fix this. ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
