Proposal for Fedora - "GKSUDO"

[David Zeuthen]

On Thu, 2007-12-06 at 16:44 -0500, Colin Walters wrote:
> On Thu, 2007-12-06 at 15:52 -0500, David Zeuthen wrote:
> > On Thu, 2007-12-06 at 14:59 +0100, Matej Cepl wrote:
> > > On Tue, 04 Dec 2007 11:38:47 +0100, Patrice Dumas scripst:
> > > > Unless there is something special for these pieces of code, anybody can
> > > > submit those packages to fedora through the usual review process.
> > > 
> > > Not sure, ask davidz, but I am afraid most of them will horribly clash 
> > > with PolicyKit/ConsoleKit.
> > 
> > Right, it's going to be confusing to developers because they won't know
> > what to use. So please don't do this. Also note that Ubuntu is switching
> > away from gksudo to PolicyKit
> > 
> > https://wiki.ubuntu.com/DesktopTeam/Specs/PolicyKitIntegration
> 
> Well, right - for their apps like the software updater.
> 
> But we still need a generic mechanism for asking a "wheel user" for a
> password in a nice way to run an arbitrary command.  Use cases being
> "rmmod iw3945" as spot mentioned, or developers restarting tomcat on
> their local machine, editing /etc/yum.repos.d, really the list is
> endless.  I guess though a sane way to start would be to restrict
> "arbitrary command" to "tty app", without also supporting X apps.

Sure, we should just ship with an /etc/sudoers that allows you to run
any command if you are in the 'wheel' group. Personally I just use 'sudo
su -', enter my password, and off I go with the root shell.

> > That, we already have consolehelper which does this. 
> 
> I guess you could make a consolehelper app called "runcommand" or
> something which had UGROUPS=wheel?  Hm, I can't get it to work in a
> quick attempt.

The point is that you want fine-grained access for this. So the way I
imagine this is going to work is that you can do

 $ polkit-auth --user the_wife --grant
org.fd.policykit.run-as.system-config-display

to grant the_wife the authorization to always run system-config-display.
Or you can go crazy and require what authentication is needed via
polkit-action(1) or the GTK+ tool

http://people.freedesktop.org/~david/polkitg-auth-1.png
http://people.freedesktop.org/~david/polkitg-auth-2.png
http://people.freedesktop.org/~david/polkitg-auth-3.png

to e.g. configure that system-config-display needs the users own
password or an administrator password.

> > And soon, as I
> > wrote about in the other mail, we'll have the PolicyKit-powered
> > consolehelper replacement that will make it very easy to manage
> > authorizations on a per-app basis.
> 
> I'm just hoping we can land the bits so that removing the root password
> from Fedora is as simple and manageable as flipping one switch - and
> then we can flip that switch by default for the desktop config.  And
> that we have a nice UI for prompting for the user password to run
> arbitrary commands.

That's the plan. PolicyKit 0.8 (out in a 4-6 weeks or so) will get two
extra UNIX user groups so we'll end up with three groups defining what
users can do

 wheel           : gives you full root access through sudo

 polkit_admin    : defines administrative users; any PolicyKit auth
                   dialog that asks for an administrator to authenticate
                   will allow you to select one of these users in this
                   group to authenticate. It looks like this

http://hal.freedesktop.org/docs/PolicyKit-gnome/auth-wheel-group-1.png
http://hal.freedesktop.org/docs/PolicyKit-gnome/ref-auth-daemon.html

 polkit_lockdown : any user in this UNIX group cannot even authenticate
                   to gain PolicyKit authorizations (think guest/KIOSK)

As you can imagine this gives you a lot of flexibility in defining what
a user can and can't do.

With this, specifically for the desktop live CD we'll just

 - rewrite /etc/sudoers to allow any command
 - disable root logins and unset the root password (See Ubuntu)

which can all be achieved from the Kickstart file (as such, these
changes will end up on installed copies of the OS).

There's also some firstboot work in adding toggles for these three
groups (specifically someone _needs_ to be in the 'wheel' group) but
that shouldn't be too hard. There's also Anaconda work in making sure
the root password isn't asked for. Should be trivial as well.

That's the plan anyway. Someone should probably write a feature page;
Colin, are you up for that? :-)

      David