---++ Description of problem unable to use PAM groups to define Access Control Lists in pacemaker ---++ Version-Release number of selected component (if applicable) pacemaker-cli-1.1.12-22.el7_1.2.x86_64 pacemaker-1.1.12-22.el7_1.2.x86_64 ---++ How reproducible always. ---++ Steps to Reproduce # create a group groupadd rogrou # create a user useradd -G haclient,rogroup rouser # verify id rouser # uid=4101(rouser) gid=4101(rouser) # groups=4101(rouser),189(haclient),10001(rogroup) # enable acl pcs acl enable # define role pcs acl role create readonly read xpath /cib # add group pcs acl group create rogroup readonly # verify pcs acl # ACLs are enabled # # Group: rogroup # Roles: readonly # Role: readonly # Permission: read xpath /cib (readonly-read) ---++ Actual results [rouser@nodea ~]$ pcs resource Error: unable to get resource list from crm_resource Error performing operation: Permission denied ---++ Expected results resource status shown. ---++ Notes Directly assigning roles to the user works (pcs acl user create rouser readonly), but groups should be used as multiple users need the same permissions.
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.