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?
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".
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?
If you uncomment the polkit.log calls in
/usr/share/polkit-1/rules.d/49-polkit-pkla-compat.rules and then run
sudo /usr/lib/polkit-1/polkitd --replace
from a terminal, then you'll be able to see whether the
backwards-compat admin rule function is getting called. Similarly,
if you edit /usr/share/polkit-1/rules.d/40-debian-sudo.rules and
/usr/share/polkit-1/rules.d/50-default.rules to look like this:
polkit.addAdminRule(function(action, subject) {
polkit.log('Using sudo group');
return ["unix-group:sudo"];
});
polkit.addAdminRule(function(action, subject) {
polkit.log('Using default');
return ["unix-user:0"];
});
then they'll log when called.
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.
smcv
