[Pkg-utopia-maintainers] Bug#566586: Please allow any actions by group "sudo" on the console

[Josh Triplett]

On Sun, Nov 20, 2011 at 03:07:47PM +0100, Luca Capello wrote:
> 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.

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

> On Tue, 05 Apr 2011 06:45:53 +0200, Josh Triplett wrote:
> > 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
> 
> 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>

Thanks.

> On Sat, 18 Sep 2010 02:28:22 +0200, Josh Triplett wrote:
> > On Sat, Sep 18, 2010 at 12:33:31AM +0200, Michael Biebl wrote:
> >> Also CCing Josh here, as he filed #566586 which is similar to this bug report
> >> and should probably merged.
> >> 
> >> Josh, please speak up if the aforementioned proposal does not suit your needs
> >> and we have to to keep track of that in a separate bug report.
> >
> > The proposed change certainly seems to make sense for group sudo, since
> > by current default that group has sudo permission with their own
> > password.
> >
> > For the purposes of bug 566586, though, I'd like to have a group which
> > doesn't need to enter a password at all, rather than one which needs to
> > enter their own password.
> 
> I disagree with such a configuration shipped by default, is there any
> rationale for it?

Much the same as the rationale for supporting group sudo by default: it
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.

> 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).

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.

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

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