Bug 1214026 - PolicyKit should authorize groups using getgroups() rather than getgr*()
Summary: PolicyKit should authorize groups using getgroups() rather than getgr*()
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: polkit
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jan Rybar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1694611 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-21 19:03 UTC by Stephen Gallagher
Modified: 2022-02-03 10:22 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-19 13:49:05 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Stephen Gallagher 2015-04-21 19:03:54 UTC
Description of problem:
getgroups() and getgrnam()/getgrgid() are not always reciprocal. For example, groups that are specified in both /etc/groups and in a FreeIPA domain will be associated with the user when they log in (via the initgroups() routine) and will therefore be visible with getgroups().

However, because glibc has not yet implemented https://sourceware.org/glibc/wiki/Proposals/GroupMerging, the reverse is not true.

The canonical source of the groups that a user belongs to is maintained by the kernel and associated during initgroups(). This is where permissions such as filesystem access is handled. PolicyKit should use these groups rather than attempting to compare the list of users from getgr*() to the requesting user.



Version-Release number of selected component (if applicable):
polkit-0.112-9.fc22.x86_64

How reproducible:
Every time

Steps to Reproduce:
1. Join a Fedora 22 client to a FreeIPA domain
2. Install and start the docker service on this client
3. Create a user group in FreeIPA with the name 'wheel' and the GID 10
4. Add a user to this group
5. Log into the client with that same user. (Must happen after the user was added to the group)
6. Run 'sudo docker ps'
7. Run 'pkexec docker ps'

Actual results:
The sudo command succeeds and presents the list of running docker containers.
The pkexec command fails and reports authorization failure.

Expected results:
Both approaches should succeed.

Additional info:
This is a command-line example; if pkexec worked, the same user should be able to log into the Cockpit management console and mange the docker containers from there, since it also uses the polkit authorization framework.

Comment 1 Miloslav Trmač 2015-04-21 20:13:01 UTC
Thanks for your report.

Subtasks:
* In authentication_agent_initiate_challenge, store also the original identities before expanding groups to contained users.
* In polkit_backend_interactive_authority_authentication_agent_response, use the original identies + getgrouplist() instead of the expanded list.
* Document that the user identities in BeginAuthentication may not be comprehensive.
* Correspondingly update PolkitAgentTextListener to let the user enter any user name
* … and make similar changes to the GNOME/KDE polkit agents.

Comment 2 Fedora End Of Life 2016-07-19 13:49:05 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 3 Stephen Gallagher 2016-11-21 18:38:46 UTC
https://lists.freedesktop.org/archives/polkit-devel/2016-November/000513.html also just brought up that in very large environments (tens of thousands of users/groups), it's often desirable to set the SSSD option `ignore_group_members` in order to avoid extremely poor performance when a getgr[nam|id]() call is made. In this situation, the group membership is intentionally zeroed out. The output of `getgroups()` however will be accurate for the requested user.

We should really consider prioritizing this fix, as SSSD presence in large environments is becoming far more prevalent and more such issues are being reported.

Comment 4 Ian Collier 2019-06-19 14:11:12 UTC
I've just come across a weird issue on Fedora 30 which I believe boils down to this bug.

We lock the root password on our systems, and create users who are members of specified admin groups.  One of these groups is the group of local admin users, and these users are created with that group as their primary group.

$ getent group linuxadminslocal
linuxadminslocal:x:500:
$ getent passwd imc
imc:x:602:500:Ian Collier,,,:/home/imc:/bin/bash

However, on a newly installed system (which doesn't yet have any network 
accounts), when we tell polkit that this Unix group is a valid
administrator group, polkit still insists on asking for the root
password (even though sudo works correctly):

$ cat /etc/polkit-1/rules.d/40-cs-admin.rules
polkit.addAdminRule(function(action, subject) {
  return ["unix-group:wheel","unix-group:linuxsysadmins","unix-group:linuxadminslocal"];
});

$ pkexec
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ====
Authentication is needed to run `/bin/bash' as the super user
Authenticating as: root
Password: 

Editing the group file to add my userid explicitly to that group
fixes this.

Comment 5 Pierre Ossman 2019-09-26 12:49:33 UTC
Upstream issue:

https://gitlab.freedesktop.org/polkit/polkit/issues/24

Comment 6 Pierre Ossman 2019-11-04 12:26:42 UTC
*** Bug 1694611 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.