Looks like pacemaker issue to me:
1. pcs sets ACLs in the CIB just fine
2. I found "acl_group" in pacemaker sources only in xml/acls-2.0.rng and include/crm/msg_xml.h: # define XML_ACL_TAG_GROUP "acl_group", but XML_ACL_TAG_GROUP is not used anywhere as far as I can see (searching through upstream sources commit e54e3c151764aed9c423d9be2f144bdc35ecda26).

This was always planned, could have sworn I implemented it. 
No idea where it went, perhaps we were waiting for the group info to be exposed in libqb?

Capacity constrained, bumping to 7.4

This will not be ready in the 7.4 timeframe.

Due to time constraints, this will not make 7.5

*** Bug 1709163 has been marked as a duplicate of this bug. ***

*** Bug 1709157 has been marked as a duplicate of this bug. ***

[Only after going through the whole thought process in this comment,
I realized PAM groups is a complete misnomer(!), fixing title to that
effect]


Preliminary analysis
====================

Current state
-------------

There are authentication relevant 2 APIs used in the broad cluster
stack:

1. libc functions (possibly backend-rewired through NSS in case of
   glibc), used implicitly (NSS non-portable), is a synonym to
   "systems means of doing authentication and respective book-keeping"

2. PAM, used explicitly, with application granularity, widely portable


Details regarding current state
-------------------------------

Ad. 1:  since this is an implicit approach, it's assumed everywhere
        unless explicitly told otherwise for 2. below

Ad. 2:

* pacemaker
  - optional dependency
  - when present (it is with default spec file), used to authenticate
    incoming requests whenever current working base carries either
    remote-{tls,clear}-port configuration set up, and the client side
    will try to connect there whenever it sees CIB_port + some more
    environment variables, using a mix of 1. and 2.:
    - 1. is used to verify the user presented at such enrollment
      ("hacluster" by default) is a member for "haclient" group
    - 2. is consequently used check that presented user name + password
      (possibly consulting whole another database compared to what's
      used in 1.!) is fine, unless PAM libraries were not available
      at configure time (effectively, only group membership is used
      to decided the acceptance)
  - normally, and in upstream settings, pacemaker doesn't ship with any
    specific PAM configuration -- rather, "login" [*] is hardwired as
    a default PAM configuration provider (service name), unless
    CIB_pam_service environment variable overrides that

  [*] /etc/pam.d/login is delivered with util-linux on Fedora systems
      that can be considered as the most authoritative configuration
      regarding what to consult when allowing users to the live system;
      moreover, on Fedora, it contains:

> #%PAM-1.0
> auth       substack     system-auth
> auth       include      postlogin
> account    required     pam_nologin.so
> account    include      system-auth
> password   include      system-auth
> # pam_selinux.so close should be the first session rule
> session    required     pam_selinux.so close
> session    required     pam_loginuid.so
> session    optional     pam_console.so
> # pam_selinux.so open should only be followed by sessions to be executed in the user context
> session    required     pam_selinux.so open
> session    required     pam_namespace.so
> session    optional     pam_keyinit.so force revoke
> session    include      system-auth
> session    include      postlogin
> -session   optional     pam_ck_connector.so

      whereas system-auth (/etc/pam.d/system-auth) here by default 
      consults OS with native calls as if 1. was used (however, user
      is free to change that any time, hence why I am pointing such
      1. vs 2. discrepancy out)

* pcs
  - required dependency even if not declared so(!)
    -> [bug 1717113]
  - it is used to authenticate token-lacking users, in the same
    mix of 1. and 2. as pacemaker
  - it does carry its own "pcsd" service PAM configuration file, it only
    refers to system-auth (similar to above situation, but more
    direct and easier to follow; plus there's apparently a special
    treatment for Debian, since it may have more systemic separation
    of generic types of application)


Is combining 1. and 2. sane?
----------------------------

Moving now to evaluation role, it seems that combining 1. and 2. is
_pretty unreasonable_.  You basically grab entities from two not
necessarily correlated baskets, only to require some properties to
apply for both of them in separation (resembling security through
obscurity at the cost of flexibility!):

- 1.: user X exists in the native userland + is a member of some group

- 2.: user X exists in the arbitrary other authentication scheme, where
      it also possess the matching password (or the "auth" is otherwise
      evaluated to pass; see, e.g., pam_userdb, pam_rootok, ...)

It can be also dangerous at times when users start mangling with that,
not aware of the totally hidden intertwining.

The idea would be:

- make pacemker periodically refresh a list of ACLs-applied group
  names into an externalized file

- device new pam_cluster.so that does the following:
  . when the above file exists and is reasonably up to date,
    do nothing to refresh it, otherwise read on-disk CIB,
    parse which groups are referred to here
  . if the file is empty, then if the user does exist in
    the system, is proved to be authentic, and is also a member
    of haclient group, inject that group for sure (may not be
    effectively used before...)
  . else, if it's not empty, ditto but also inject intersection
    of such groups (which can be empty, haclient is the only, then)
  . else, if no such match found, continue with what whatever else
    is configured (if possible, unsure) ... and for when some other
    method succeed, make the module operate in piggy-back mode
    (again, not sure if possible) so that it consults additional
    /etc/security/pam_cluster.conf file and assigns haclient
    + whichever groups are matching in this file, provided that
    there's at least a single match on such system-absent user name

- consequently, start relying fully on PAM only (i.e. just 2. and
  no 1., 2. can defer to 1. by configuration); this step doesn't even
  need a modification in the code (notice that "haclient" is already
  being injected), first for pre-existing cases only:
  . devise a common service name to be referred to from cluster-wide
    components that have interest in talking PAM (likely just pcsd
    and pacemaker), so at least the approach is somewhat unified
  . such "pam.d/cluster" is shipped in the same package as
    pam_cluster.so is, and is required by all components that
    refer to it in their own service PAM configurations

- switch whole ACLs scheme in pacemaker to only use this as well
  (no more 1., just 2. that can sort of works like 1. with some
  additions)

(
- possible fallback: either use exclusively 1., or the pam_cluster.so
  can be modularly delivered as a code module totally bypassing PAM,
  so that it can still be reused with multiple components uniformly.
  PAM is effectively not needed for described functionality except for
  user configuration of extra user DB for which pam_cluster.so would
  play said piggy-backing
)


This way, semantics of groups in ACLs is clearly given with a full
flexibility (system-native users need to match system-native group
membership arrangement, while strictly disjoint "made-up" PAM users
need to match system-native groups per an external mapping in
/etc/security/pam_cluster.conf).


>>> next to come: Detailed action plan >>>

I'm thinking it might be a good idea to split this up into two BZs, one for implementing acl_group, and the other for using PAM to authenticate ACL users and groups.

I cloned Bug 1724310 to split this into two logical pieces; that bug now covers implementing acl_group, and this bug focuses on PAM integration.

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.