[Pkg-utopia-maintainers] Bug#1023393: policykit-1: Not prompted to authenticate with my own identity any more

[Sam Morris]

On 03/11/2022 13:39, Simon McVittie wrote:
> On Thu, 03 Nov 2022 at 11:51:52 +0000, Sam Morris wrote:
>> Here's my configuration:
>>
>>      # cat /etc/polkit-1/localauthority.conf.d/60-sam.conf
>>      [Configuration]
>>      AdminIdentities=unix-user:sam.morris at domain.example.com
> 
> Is that really your Unix/PAM login name, the one you'd get from `id -nu`
> or `su - $user` or similar? Or is your login name something like sam.morris
> or sam?

Yes - the user account lives in an Active Directory domain which is 
projected into the POSIX world by FreeIPA. The user name is the SAM 
Account Name of the user @ The AD domain's DNS FQDN.

> The usual setup with a modern polkit version is that the admin identities
> are handled by /usr/share/polkit-1/rules.d/40-debian-sudo.rules,
> which returns "unix-group:sudo", meaning "any member of the sudo group
> is a local sysadmin".

Having my username in the pklocalauthority like that is sort of a 
workaround for a number of unfortunate things about how polkit 
enumerates groups & because FreeIPA isn't able to put AD users into 
netgroups.

You're right, adding my user to the (local) sudo group will probably do 
the job.

> It's usually unnecessary to configure this, either in the old PKLA
> backend or in the newer JS backend, so the way this interoperates with
> the legacy PKLA configuration is unlikely to be particularly well-tested.
> 
> I wonder whether the problem here might be that 40-debian-sudo.rules is
> sequenced earlier than 49-polkit-pkla-compat.rules, which means only the
> function defined in 40-debian-sudo.rules gets called, and the one in
> 49-polkit-pkla-compat.rules is ignored?

You're right. I actually just commented out the contents of 
40-debian-sudo.rules entirely. polkit immediately reloads the rules and 
my pkcheck command is once again prompting me for my own credentials.

> polkit keeps calling admin rule functions until one returns a non-empty
> result, so only the first one that returns a result (in lexicographic
> order by filename) is practically useful.

Argh, that's a really annoying. I wonder why they don't call all the 
admin rules and collect all of the results...

Anyway, that's all I need to get our systems working sensibly again.

But I suppose this should become a bug against polkitd-pkla since in 
practice its 49-polkit-pkla-compat.rules will never be called since 
40-debian-sudo.rules is called first.

Perhaps one solution would be to renumber to << 40, and ship a 
pklocalauthority config file with 'unix-group:sudo'. This will ensure 
that systems where polkitd-pkla is installed will match the default 
behaviour of systems where it isn't installed.

>      smcv

Thanks for your help! :)

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9