Skip to content

Med: daemons: Fix user/group checking in based.#4055

Merged
nrwahl2 merged 1 commit intoClusterLabs:mainfrom
clumens:fix-group-check
Feb 10, 2026
Merged

Med: daemons: Fix user/group checking in based.#4055
nrwahl2 merged 1 commit intoClusterLabs:mainfrom
clumens:fix-group-check

Conversation

@clumens
Copy link
Contributor

@clumens clumens commented Feb 10, 2026

This fixes a bug introduced by bcc7c90. The group members returned by getgrnam will only include those users that are listed in /etc/group for that group. It won't include any users for which a group is their primary.

In other words, if this is what's in /etc/passwd:

hacluster:x:189:189:cluster user:/var/lib/pacemaker:/sbin/nologin

And this is what's in /etc/group:

haclient:x:189:

Then getgrnam will not list hacluster as a member of the haclient group and is_daemon_group_member will return false. We need to re-introduce the primary group check to fix this.

@clumens clumens requested a review from nrwahl2 February 10, 2026 16:30
@clumens
Copy link
Contributor Author

clumens commented Feb 10, 2026

@nrwahl2 You might be planning to look into this, but just in case you don't get around to it, here's a fix. This is needed to make #4051 work.

Also, I haven't done anything about the fact that we have largely redundant code in pcmk__is_user_in_group.

/* If that didn't work, we need to check if CRM_DAEMON_GROUP is a secondary
* group for the user - that is, are they listed in /etc/group for that
* group?
*/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code looks good, thanks!

One thing I'm on the fence about comment-wise, is whether to state explicitly that group->gr_mem includes only the users listed in /etc/group -- not necessarily all members of the group. To make it super clear why this isn't enough on its own. Some of the other comments could probably be trimmed down or removed if you wanted.

On the other hand, you explained it well in the commit message. I made sure to check the 14d9ae4 commit message before bcc7c90, but I didn't realize that this loop wouldn't catch a primary group match.

Up to you. Feel free to merge this as-is. I appreciate you taking care of this. I hadn't started on it yet.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated and shortened comments. It's always kind of a struggle to know how much to add to inline comments vs. in the commit message. Sometimes commit messages don't make a lot of sense without the context of what comes before and after, unless you get really verbose and redundant. On the other hand, I'd love to avoid the "what exactly was I thinking five years ago" situation that comes up so often.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I totally agree. I just try to avoid comments stating WHAT fairly obvious code is doing, unless it's a long or complicated function where those comments serve more as visual delimiters than as explanations.

This fixes a bug introduced by bcc7c90.  The group members returned
by getgrnam will only include those users that are listed in /etc/group
for that group.  It won't include any users for which a group is their
primary.

In other words, if this is what's in /etc/passwd:

    hacluster:x:189:189:cluster user:/var/lib/pacemaker:/sbin/nologin

And this is what's in /etc/group:

    haclient:x:189:

Then getgrnam will not list hacluster as a member of the haclient group
and is_daemon_group_member will return false.  We need to re-introduce
the primary group check to fix this.
@nrwahl2 nrwahl2 merged commit eaef583 into ClusterLabs:main Feb 10, 2026
1 check passed
@clumens clumens deleted the fix-group-check branch February 11, 2026 14:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants