Evaluating membership of an AD group for polkit authorization

[Miloslav Trmac]

Hello,
2016-11-21 0:34 GMT+01:00 zero four <zfnoctis at gmail.com>:

> I am attempting to join Linux workstations to a relatively large domain
> (150k users, 50k groups) using sssd, and I am wanting to allow members of
> specific AD groups to perform elevated actions using polkit.  Currently
> sssd cannot handle that many nested groups and users without setting
> "ignore_group_members = true". However it appears that polkit verifies a
> user's authorization by enumerating all members of the authorized groups
> and then determining if the user is in that list, rather than looking up
> the group memberships of the user attempting elevation.  This results in
> polkit showing zero users as having the ability to elevate privileges.  I
> believe sudo evaluates group memberships of the user, which would explain
> why I can add AD groups to the sudoers file and have it work, even though
> "ignore_group_members = true" is set in sssd.conf.
>
> I understand that this may seem like a problem solely with sssd, but it
> does appear to be a less efficient way of determining elevation rights for
> users, at least in this case.  Would it be possible for polkit to instead
> check the group memberships of the user attempting elevation, or at least
> make that a configuration option for polkit?
>

Yeah, that would be nice:
https://bugzilla.redhat.com/show_bug.cgi?id=1214026 contains a bit more for
what that would involve. It *should* be possible but it is a bit involved
because currently the list of usernames is passed to the various
(deskop-specific) authentication agents, so a big part of the work is
researching whether/how it would affect them.

I’m afraid I don’t know of anybody working on this at the moment; patches,
or research of the major agent implementations, would definitely be welcome.
    Mirek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/polkit-devel/attachments/20161121/82e93180/attachment.html>