Description of problem: Changelog shows: * Sun Sep 02 2018 rapsys <rapsys> 2.6-4.mga7 + Revision: 1256312 - Fix tmout warning by avoiding resourcing of /etc/security/shell with a new SECSHELL variable When I run msec-gui I see that the last time the weekly check ran was last September (daily check did run today, though) And for several weeks I started noticing (but may have been longer) that the SHELL_TIMEOUT variable in .etc.security/msec/security.conf does not work anymore, During many years any terminal window closed after the timeout value was reached but lately this does not happen anymore. So I suspect that on 02 Sep things were inadvertently changed so that the timeout warning disappreared but other things stopped working as intended. For that reason I will try and add <rapsys> in the cc-field.
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 .....
Assignee: bugsquad => mageiatoolsCC: (none) => marja11
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!