[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 14:57 +0000, cfpublic1 at verimatrix.com wrote:
> > 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

I'm going to guess you were using the corosync 1 plugin, and that it
ran everything as root. I never worked with that code, so it's just a
guess :)
-- 
Ken Gaillot <kgaillot at redhat.com>