On Thu, 2018-09-27 at 10:23 +0000, cfpubl...@verimatrix.com wrote: > > > With pacemaker 1.1.17, we observe the following messages during > > > startup of > > > pacemaker: > > > 2018-09-18T11:58:18.452951+03:00 p12-0001-bcsm03 > > > crmd[2871]: warning: > > > Cannot execute '/usr/lib/ocf/resource.d/verimatrix/anything4': > > > Permission denied (13) > > > 2018-09-18T11:58:18.453179+03:00 p12-0001-bcsm03 > > > crmd[2871]: error: > > > Failed to retrieve meta-data for ocf:verimatrix:anything4 > > > 2018-09-18T11:58:18.453291+03:00 p12-0001-bcsm03 > > > crmd[2871]: error: No > > > metadata for ocf::verimatrix:anything4 > > > > > > > Could it be as simple as > > /usr/lib/ocf/resource.d/verimatrix/anything4 not having the execute > > bit set (for the user)? > > The OCF agent is not physically located there. > /usr/lib/ocf/resource.d/verimatrix is a symbolic link that points to > a directory in our software distribution. That part is not reachable > for "other". > > > > > > > It seems that on startup, crmd is querying the meta-data on the > > > OCF > > > agents using a non-root user (hacluster?) while the regular > > > resource > > > control activity seems to be done as root. > > > The OCF resource in question intentionally resides in a directory > > > that > > > is inaccessible to non-root users. > > > > Why? You can selectively grat access (man setfacl)! > > That's an option, thank you. > > > > > > > Is this behavior of using different users intended? If yes, any > > > clue > > > why was > > > it working with pacemaker 1.1.7 under RHEL6? > > > > Finally: Why are you asking thei list for help, when you removed > > execute permission for your home-grown (as it seems) resource > > agent? > > What could WE do? > > I would like to understand the concept behind it to determine the > best solution. If there was a way to configure or tell crmd to do the > meta-data query as root, I would prefer that. It's because even if > the actual access to the OCF agent scripts worked, we would hit the > next problems because some OCF scripts use the "ocf_is_root" function > from /usr/lib/ocf/lib/heartbeat/ocf-shellfuncs. These OCFs would fail > miserably. > So before I revisit all our OCFs to check if the well-behave if > called as non-root, I wanted to check if there is another way. > > Thanks, > Carsten
The crmd does indeed run meta-data queries as the hacluster user, while the lrmd executes all other resource actions as root. It's a longstanding goal to correct this by making crmd go through lrmd to get meta-data, but unfortunately it's a big project and there are many more pressing issues to address. :-( There's no workaround within pacemaker, but the setfacl approach sounds useful. As a best practice, an agent's meta-data action should not do anything other than print meta-data. I.e. many agents have common initialization that needs to be done before all actions, but this should be avoided for meta-data. Even without this issue, regular users and higher-level tools should be able to obtain meta-data without permission issues or side effects. -- Ken Gaillot <kgail...@redhat.com> _______________________________________________ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org