ID: 6713
Title: Fixed monitoring of piggyback based services when "No agent" is configured
Component: Core & setup
Level: 1
Class: Bug fix
Version: 1.6.0i1
Check_MK was not correctly discovering services using piggyback data when a
host (e.g. a docker container) has "No agent" configured.
ID: 6711
Title: Change Check_MK site umask to prevent "world" access
Component: Site Management
Level: 1
Class: Security fix
Version: 1.6.0i1
To prevent Check_MK site files from being read by any local system user the Check_MK
sites now have a umask of 0007 set.
The effect of this change is that new files and directories that are created in
the context of the site user are not accessible by "world" users. These are
local system users that are neither the site user nor members of the site
group.
If you don't like this, you can change the umask back to e.g. 0002 in the file
<tt>~/.profile</tt>.
ID: 6630
Title: df: Do not ignore filesystems mounted at /var/lib/docker and /var/lib/docker-latest
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 1.6.0i1
We do not want to discover the container filesystems, but previously, the filtering had
been too aggressive. This has been fixed.
ID: 6710
Title: Limit crash reporting functionality to permitted users
Component: Multisite
Level: 1
Class: Security fix
Version: 1.6.0i1
The crash reporting functionality of the GUI, which shows a lot of detailed
information about the internal state of the GUI, has been limited to be shown
only to permitted users.
The crash report could be used by attackers to get internal information about
the application state and secrets processed by the GUI.
All not permitted users will now only see a short message about the occurred
crash. Some more information is written to <tt>var/log/web.log</tt>.
Only authenticated administrative users are allowed to see and submit crash
reports by default.
If you like to give all your users the right to see and send crash reports give
them the permission "See crash reports"
A problem with this change may be that some crashes occur only in very specific
situations, for example for specific users. In such a case it may be hard to
get detailed information about the situation when the crash reporting is not
available. We plan to add an improved crash reporting in future versions to
make all occurred crashes available to the Check_MK administrator for later
debugging.
CMK-1037
ID: 6709
Title: Fixed possible information disclosure to apache log when editing users
Component: WATO
Level: 1
Class: Security fix
Version: 1.6.0i1
An administrator has the ability to create new users. The credentials of a
newly created user were visible within the HTML of the resulting web page as
GET parameter of various hyperlinks. If one of these links was clicked, the
credentials were stored in the administrator’s browser history and in the access
logs of the server.
ID: 6574
Title: azure_databases: Monitor Azure databases
Component: Checks & agents
Level: 1
Class: New feature
Version: 1.6.0i1
This werk adds a check reporting the state of monitored azure databases.
You can configure levels for CPU utilization, Database throughput units,
and used storage in percent. Additionally connections are displayed.
ID: 6478
Title: synology_raid: Fixed crash on devices with more possibles raid states
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 1.6.0i1
Newer devices can have more states than older one. This check does not crash
anymore if such a state occurs.
ID: 6572
Title: azure_agent_info: General state of Azure agent
Component: Checks & agents
Level: 1
Class: New feature
Version: 1.6.0i1
Add a check reporting on the general state of the azure special agent.
It reports the remaining API calls (which are limited to 15.000 per hour),
the monitored groups and encountered issues.
ID: 6663
Title: BI configuration: WATO slave sites without user login now also receive BI configuration changes
Component: Multisite
Level: 1
Class: Bug fix
Version: 1.6.0i1
If a WATO slave site had no direct login access configured, it also did not receive any changes
within the BI configuration. As a result, BI checks running on the slave site never received
configuration updates in time. This has been fixed.