If you have msec set to enforce perms (like in secure mode), it looks like it doesn't check whether the files/directories actually exist before trying to chmod/chown them. One of the defaults (for secure) to enforce is ownership svn.svn for /var/lib/svn. When the subversion-server isn't installed, that directory doesn't exist, nor does the user and group svn. This causes errors in the logs (and daily mail report). msec should check that things exist before it tries to chmod/chown them. This is a duplicate of Mandriva Bug 63875 https://qa.mandriva.com/show_bug.cgi?id=63875 and it has been at least partially fixed there, although this should really get fixed upstream by Eugeni (new upstream URL given in URL field).
(also add the real maintainer of msec)
CC: (none) => dmorganec
A fix for this issue was done for Mandriva 2011. It would be nice to get the fix into Mageia 1 (and Cauldron). http://lists.mandriva.com/security-announce/2011-11/msg00024.php
Here is the patch itself: http://svn.mandriva.com/svn/packages/cooker/msec/current/SOURCES/msec-0.80.10-remove.svn.patch
Keywords: (none) => PATCH
Assignee: ennael1 => dmorganec
pushed in the BS
Assignee: dmorganec => qa-bugs
On the i586 updates testing mirrors, the msec and msec-gui packages are not signed.
CC: (none) => davidwhodgins
(In reply to comment #5) > On the i586 updates testing mirrors, the msec and msec-gui packages are not > signed. misc, I think your puppet rework has broken package signing :/
CC: (none) => misc, tmb
Ok, found and fixed the problem. I submitted a msec-0.80.10-2.7.mga1 to updates_testing that should be properly signed.
Confirmed msec runs and doesn't give the errors about svn on i586. Note to QA: we are testing the same update candidate from Bug 2808
x86_64 There are still some lingering problems with msec. Should these be looked at as part of the update? It produces errors related to missing sectool configuration (bug 2808) ERROR: Unable to load configuration file /etc/security/msec/perm.audit_weekly.sectool: [Errno 2] No such file or directory: '/etc/security/msec/perm.audit_weekly.sectool' ERROR: Unable to load configuration file /etc/security/msec/perm.netbook.sectool: [Errno 2] No such file or directory: '/etc/security/msec/perm.netbook.sectool' ERROR: Unable to load configuration file /etc/security/msec/perm.audit_daily.sectool: [Errno 2] No such file or directory: '/etc/security/msec/perm.audit_daily.sectool' ERROR: Unable to load configuration file /etc/security/msec/perm.secure.sectool: [Errno 2] No such file or directory: '/etc/security/msec/perm.secure.sectool' ERROR: Unable to load configuration file /etc/security/msec/perm.webserver.sectool: [Errno 2] No such file or directory: '/etc/security/msec/perm.webserver.sectool' ERROR: Unable to load configuration file /etc/security/msec/perm.fileserver.sectool: [Errno 2] No such file or directory: '/etc/security/msec/perm.fileserver.sectool' ERROR: Unable to load configuration file /etc/security/msec/perm.standard.sectool: [Errno 2] No such file or directory: '/etc/security/msec/perm.standard.sectool' It also gives an INFO warning of a missing file if no exceptions exist. INFO: loading exceptions file /etc/security/msec/exceptions: No such file or directory The Monthly or Manual checks don't run properly when run manually and show as never having been run in the GUI. The GUI doesn't update the last run time after a check is run until it is closed and restarted. These are not regressions but this has caused controversy in the past. Confirmed /var/lib/svn is not permission checked when selecting Secure level. Testing complete x86_64
Claire, when/where do you see those errors related to missing sectool configuration? I've never seen those errors.
Here is the full terminal output, started with $ mcc. "/usr/sbin/drakbackup" is not executable [Backups] at /usr/sbin/drakconf.real line 822. "/usr/sbin/drakvirt" is not executable [Virtualization] at /usr/sbin/drakconf.real line 822. "/usr/sbin/tomoyo-gui" is not executable [Tomoyo Policy] at /usr/sbin/drakconf.real line 822. INFO: Starting gui.. ERROR: Unable to load configuration file /etc/security/msec/perm.audit_weekly.sectool: [Errno 2] No such file or directory: '/etc/security/msec/perm.audit_weekly.sectool' ERROR: Unable to load configuration file /etc/security/msec/perm.netbook.sectool: [Errno 2] No such file or directory: '/etc/security/msec/perm.netbook.sectool' ERROR: Unable to load configuration file /etc/security/msec/perm.audit_daily.sectool: [Errno 2] No such file or directory: '/etc/security/msec/perm.audit_daily.sectool' ERROR: Unable to load configuration file /etc/security/msec/perm.secure.sectool: [Errno 2] No such file or directory: '/etc/security/msec/perm.secure.sectool' ERROR: Unable to load configuration file /etc/security/msec/perm.webserver.sectool: [Errno 2] No such file or directory: '/etc/security/msec/perm.webserver.sectool' ERROR: Unable to load configuration file /etc/security/msec/perm.fileserver.sectool: [Errno 2] No such file or directory: '/etc/security/msec/perm.fileserver.sectool' ERROR: Unable to load configuration file /etc/security/msec/perm.standard.sectool: [Errno 2] No such file or directory: '/etc/security/msec/perm.standard.sectool' INFO: loading exceptions file /etc/security/msec/exceptions: No such file or directory INFO: No exceptions loaded INFO: Detected base msec level 'standard' It repeats whenever the msec gui is started.
Thanks for the clarification Claire. At least those errors won't be seen in logs or the mail report, so they aren't a big deal. I suppose they will be fixed when Bug 2808 is. Could you please add a comment about that to Bug 2808?
Update validated Suggested advisory: ======================== Updated msec packages fix a bug: When msec is configured to enforce permissions (by default, in secure mode), it checks for non-existent user svn on directory /var/lib/svn, which also doesn't exist if subversion-server is not installed. This causes error messages to be output by msec's cron job, which appear in log files and the mail report. This update disables the permissions check on /var/lib/svn in the default configuration. References: https://bugs.mageia.org/show_bug.cgi?id=3284 ======================== Source RPM: msec-0.80.10-2.7.mga1.src.rpm Could sysadmin please push from core/updates_testing to core/updates Thank you!
Keywords: PATCH => validated_updateCC: (none) => sysadmin-bugsHardware: i586 => All
update pushed
Status: NEW => RESOLVEDResolution: (none) => FIXED