We use Sensu in our CentOS machines, which lately been upgraded to CentOS 7.
Since then, we experience weird failures with check command execution regarding permissions, specifically like the one as follows:
user sensu is a member of the group “company” and nevertheless fails to execute a simple check which instructs it to read a pid file located in /var/run/company/app.pid with permissions:
~# ll /var/run/company/
total 4
drwxr-x—+ 2 company company 60 Nov 21 14:34 .
drwxr-xr-x. 27 root root 900 Nov 21 14:36 …
-rwxr-xr-x. 1 company company 5 Nov 21 14:34 app.pid
to verify that sensu is actually is a member of the group that supposed to have permissions to this dir:
~# id sensu
uid=995(sensu) gid=1004(company) groups=1004(company),992(sensu)
as you can see, sensu, who is a member of the group company is supposed to be able to read the app.pid file inside /var/run/company, but:
{“timestamp”:“2017-11-21T15:00:13.665556+0000”,“level”:“info”,“message”:“publishing check result”,“payload”:{“client”:“XXXXXXXXXX”,“check”:{“command”:“cat /var/run/company/app.pid”,“standalone”:true,“interval”:5,“name”:“test_cat”,“issued”:1511276413,“executed”:1511276413,“duration”:0.002,“output”:“cat: /var/run/company/app.pid: Permission denied\n”,“status”:1}}}
other (badly) surprising part is that when I test the permissions manually to see if user sensu can read the dir I see that it actually can (or can’t it?):
~# sudo -H -u sensu bash -c ‘ls -las /var/run/company’
total 4
0 drwxr-x—+ 2 company company 60 Nov 21 14:34 .
0 drwxr-xr-x. 27 root root 900 Nov 21 14:36 …
4 -rwxr-xr-x. 1 company company 5 Nov 21 14:34 app.pid
of course, when I add x permission to all on the dir, the check execution succeeds, but this is an unexpected behavior.
Needless to say, I restarted the sensu-client service for the membership to take effect and also rebooted the machine just in case.
ANY help will be much appreciated.
Sensu is of version 1.0.2 running on CentOS 7.3