| Summary: | Since Sep 2018 weekly check did not run and timeout stops working | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Dick Gevers <dvgevers> |
| Component: | RPM Packages | Assignee: | Mageia tools maintainers <mageiatools> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | mageia, marja11, yvesbrungard |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | msec-2.6-5.mga7 | CVE: | |
| Status comment: | |||
|
Description
Dick Gevers
2019-01-05 12:30:58 CET
Dick Gevers
2019-01-05 12:31:57 CET
CC:
(none) =>
mageia And, for the record: systemctl status msec.service ● msec.service - LSB: Enables MSEC security policy on boot Loaded: loaded (/etc/rc.d/init.d/msec; generated; vendor preset: disabled) Active: active (exited) since Sun 2018-12-30 19:11:23 UTC; 5 days ago .....
Marja Van Waes
2019-01-05 18:13:38 CET
Assignee:
bugsquad =>
mageiatools This is related to the report mga#16356 CC:
(none) =>
yves.brungard_mageia It don't seems related to my change. I tried to revert it but it don't change a thing. The problem is that /etc/security/shell is sourced at some point. An echo TMOUT show me a value of 0 like in my shell file in 01msec.sh script. But the environnement variables are not defined in final shell. It comes from somewhere else. Okay. Then September & stopping the weekly check is just a coincidence ... Summary:
Since Sep 2 2018 fix weekly check did not run and timeout stops working =>
Since Sep 2018 weekly check did not run and timeout stops working I didn't test for the weekly and monthly check, now that you say it, I only have daily security check for my server. I tried to run it manualy, no mail, dunno why maybe it's normal with no changes ? I ran weekly check earlier today and just now from the msec gui and got a mail reading: sub: [msec] *** Diff Check on <hostname>, Jan 05 19:31:16 *** cont: Nothing has changed since the last run. But even more curious: afterwards (when restarting) the msecgui *still shows* that the last check was run last September !?!? The check use the returned ST_MTIME from the function os.stat above the /var/log/msec/security/mail.weekly.today file.
stat.ST_MTIME
Time of last modification.
http://gitweb.mageia.org/software/msec/tree/src/msec/tools.py#n54
Is there no modification really on this file because of the last check?
Indeed no: # ls -al /var/log/security/mail* -rw------- 1 root root 10807 Jan 6 01:26 /var/log/security/mail.daily.today -rw------- 1 root root 10807 Jan 5 01:27 /var/log/security/mail.daily.yesterday -rw------- 1 root root 6185 Sep 24 2017 /var/log/security/mail.weekly.today -rw------- 1 root root 6144 Sep 23 2017 /var/log/security/mail.weekly.yesterday Hello Dick, Thus closing? (In reply to papoteur from comment #9) > Thus closing? Excuse me, why? i checked since and on 3 Cauldron machines which have a weekly check supposed to be run, it did in fact not run for many months. So IMHO the bug is still valid. Moreover, the timeout has not worked either which i think it should! |