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.mor...@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
