policykit-1 supports specifying permissions for groups, not just
individual users.

Thus, please consider shipping policykit-1 with a .pkla file granting
all permissions (when on the console) to a new empty group.
The administrator can add users to this group to let them authenticate
via policykit without a password.

(Arguably, users in the "sudo" group, as root-equivalent users, ought to
have this permission, but it seems safest to have a unique group
specific to policykit-1.)

- Josh Triplett

I agree that something like this would be nice.

Ubuntu traditionally uses a system group "admin" for this kind of purpose.
Maybe this concept of a global group of "priviledged" is something we might want
in Debian as well and warrrants some wider discussion?

Are you interested in starting such a discussion (e.g. on debian-devel) and get
further input on this topic from a wider audience?

Michael

Quite possibly.  I don't think it makes sense to introduce such a
concept without it meaning "root-equivalent", though; otherwise, it
becomes very difficult to figure out whether members of that group
should have any particular permission.  Saying that the group should
mean "root-equivalent" means it ought to have any and all permissions,
though in some cases with an additional step required before getting
dangerous ones.

I seem to recall past discussions in Debian that didn't particularly
favor the concept, though I don't recall the reasons.

Done. :)

- Josh Triplett

Upon further consideration, I think it makes the most sense to just use
the existing group "sudo" for this.  Group "sudo" already has
root-equivalent permissions in the default sudoers file, and
debian-installer already has support for doing an install with sudo
configured by default and the initial user in group sudo.  Thus, making
sudo root-equivalent in policykit as well would make sense.

To do so, install the following as a new file
/var/lib/polkit-1/localauthority/10-vendor.d/sudo.pkla :

[Admin]
Identity=unix-group:sudo
Action=*
ResultActive=yes


The same file with a different unix-group: would work if you prefer to
make a new group for this.  (However, a new group has the disadvantage
of not existing by default on new installs, which means debian-installer
can't automatically put the initial user in that group.)

Hope that helps,
Josh Triplett

retitle 566586 policykit-1: Please ship with a new empty group granted all permissions on console without password
thanks

Hi there!

NB, changing the bug title to reflect the real issue, i.e. the 'without
    password' authentication.

At the beginning I thought this bug was already fixed as a #532499, but
then I found Josh's comment on #536490:

   <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536490#95>

I disagree with such a configuration shipped by default, is there any
rationale for it?  Two more problems I see:

1) the file should be in /etc/polkit-1/localauthority/10-vendor.d/, so
   the local admin can easily disable it simply by removing the file
   (given that it is a conffile, dpkg will not restore it).

2) your solution does not work when connected through SSH: pkexec still
   asks for the in-sudo-group user's password.

Thx, bye,
Gismo / Luca

Thanks, that seems reasonable.  (Ideally I'd suggest sharing that group
with the sudo package, which could ship it in the default sudoers file.)

Thanks.
makes a certain common class of configurations quite trivial, via a
single call to adduser, and unifies those configurations across sudo,
policykit, and other tools.  This configuration would introduce no
security issues, because the group will remain empty by default.  Also,
the existence of such a group would allow preseeded installers to use
it.  Debian Live images could use such a group as well, since they need
to disable anything prompting for a password.

As far as I can tell, admins can override any file in
/var/lib/polkit-1/localauthority/ via a file in
/etc/polkit-1/localauthority/ ; does that not suffice?

Furthermore, I don't see the point in disabling such a configuration;
just don't add any users to that group if you don't want to grant such
access.

When I originally set up the configuration I gave in my example, I only
cared about the at-console case, since I don't use policykit on any
systems which have remote users of any kind.  That said, for equivalence
with sudo, a group which has root equivalence whether on the console or
otherwise seems fine too.  According to the documentation, changing
ResultActive to ResultAny should have that effect, though I haven't
tested it.

- Josh Triplett