[ClusterLabs] Antw: pcmk 1.1.17: Which effective user is calling OCF agents for querying meta-data?

[cfpublic1 at verimatrix.com]

> On Thu, 2018-09-27 at 10:23 +0000, cfpublic1 at 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 <kgaillot at redhat.com>

Thank you, Ken, for the confirmation that there is no workaround within pacemaker. I will re-visit all our OCFs then and make sure they are world accessible and the meta-data action requires no special permissions.

I still wonder why it worked with pacemaker 1.1.7, though ;-)

Thanks,
  Carsten