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

[Ken Gaillot]

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>