From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: Version-Release number of selected component (if applicable): system-config-securitylevel-1.5.8.1-1 How reproducible: Always Steps to Reproduce: 1. run system-config.securitylevel 2. change any flag (ie. allowing httpd to make outgoing connections) 3. click "OK" Actual Results: the setting should change. however getsebool shows the setting is still at it's old value (inactive) and no booleans.local file is created with the adjusted setting. re-running s-c-securitylevel does not show any changes to the settings like I changed them. Expected Results: the selinux policy should be adjusted and the settings saved. Additional info:
*** Bug 171749 has been marked as a duplicate of this bug. ***
Please test out the s-c-securitylevel package from Rawhide and verify that this works for you. I just tested out with targeted policy, enforcing, and the use_nfs_home_dirs boolean. Both booleans.local is created and getsebool shows it enabled.
rebuilding the 1.6.9-1 RPM for FC4 fails to run with "Unknown error." And pre-built RPM will not install due to GLIBC version differences (2.3 vs 2.4) and older newt version (0.51.x vs 0.52.x)
Created attachment 121302 [details] Stack trace of running latest s-c-securitylevel for FC4 x86_64 nohup strace system-config-securitylevel as root switching tabs, opening HTTPD service, and un-checking "disable selinux protection for httpd daemon" I had previously used setsebool -P to turn that flag on in this case.
I am unable to reproduce this on a fresh install of FC4 with the specified version of s-c-securitylevel on x86_64. Do you have any other information which may be helpful in figuring out what is going on?
Other than this system is a FC3 to FC4 upgrade.. but I have re-installed the s-c-securitylevel package and relabeled the system and it is still doing it. Is they any way of easily debugging to see where the s-c-securitylevel program is failing to write to the file? And is there any useful information in the stack trace?
I see this behavior on a fully updated Fedora Core 4 system (system-config-securitylevel-1.5.8.1-1). Changes to the samba_enable_home_dirs boolean did not take. This is a dual-processor i686 system, clean install.
Still happening under devel, though I do not yet know why. Duping to that bug to consolidate information in one place. *** This bug has been marked as a duplicate of 202375 ***