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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
