/run/lxcfs permissions in 4.2 cause Nagios disk check failure

[rkl]

When upgrading from 4.0 to 4.2, I noticed there's a new tmpfs mount point called "/run/lxcfs/controllers" created that wasn't there in 4.0. Although almost all the contents of that mount point have world read access, for some reason the dirs /run/lxcfs and /run/lxcfs/controllers themselves only have rwx for root and no other access.

We run the Nagios client (nrpe) on all our Proxmox machines and the disk space checking module reports "permission denied" for /run/lxcfs/controllers because nrpe is run as the nagios user. Whilst adding a+rx permissions (or g+rx plus a chgrp to nagios) to /run/lxcfs and /run/lxcfs/controllers fixes the Nagios problem, it's only a temporary fix because the permissions are set to root access only on the next reboot.

So is there a reason that the /run/lxcfs and /run/lxcfs/controllers have such tight permissions when their contents are almost all readable to the world? What are the security implications of adding a+rx to those dirs? If there aren't any, then maybe Proxmox could consider that for a future update?

 

[fabian]

not having r and x permissions on a directory means you can't read any of the paths below it, even if you would have read permissions for the individual paths. it does not make sense to check disk utilization for these mounts anyway, so why don't you simple exclude them from your checks? the tmpfs /run/lxcfs/controllers is only 100k, and only contains cgroup mounts..