From dsd at laptop.org Wed Jul 2 12:07:09 2008 From: dsd at laptop.org (Daniel Drake) Date: Wed, 02 Jul 2008 15:07:09 -0400 Subject: implementing an OLPC authentication agent Message-ID: <1215025629.2672.23.camel@olpc-desktop01.laptop.org> Hi, I'm working on updating OLPC's XO platform from Fedora 7 to Fedora 9. This involves the addition/integration of ConsoleKit + PolicyKit into HAL and other such components. The Sugar UI uses HAL to request shutdown/reboot/USB mount/... Using ck-xinit-session we have successfully made ConsoleKit "aware" of sugar, and under a normal boot we can shutdown the system (the default HAL policy says that the active user can shutdown). However, if we hit ctrl+alt+F1 and login on the console, a 2nd session is created, and we can no longer shutdown through sugar because the HAL policy has the auth_admin requirement for the active user for shutting down when multiple sessions are active (sugar doesn't interpret the response and just silently fails to shut down). We'd like to fix this so that shutting down from sugar works regardless of other sessions. The first option is to just modify the policies that are installed by HAL, or modify the PolicyKit conf file to override the policies. But those files are owned by packages so (I think) we would have to create an OLPC-3 branch of those packages just to install the alternative config file. Our main Fedora guy is working hard to cut down the number of packages we have to branch, so I'm also considering other options. The second option is to implement an OLPC-specific simple authentication agent. When sugar receives the dbus exception because it couldn't shut down, it can interpret it and talk to an OLPC authentication agent for authorisation. The OLPC auth agent would authorise all auth_admin requests from the "olpc" user and deny everything else (no UI or anything, just a straightforward accept/deny). Once sugar has obtained authorisation it would then retry the shutdown and succeed. In your opinion(s), which of the above is the most sensible? I guess the 2nd option is a little nicer in that it is generic. There may be an increasing number of policies we have to override the auth_admin requirement for in future, and the 2nd option covers all of them. Thanks, Daniel From matthias.clasen at gmail.com Wed Jul 2 15:07:40 2008 From: matthias.clasen at gmail.com (Matthias Clasen) Date: Wed, 2 Jul 2008 18:07:40 -0400 Subject: implementing an OLPC authentication agent In-Reply-To: <1215025629.2672.23.camel@olpc-desktop01.laptop.org> References: <1215025629.2672.23.camel@olpc-desktop01.laptop.org> Message-ID: On Wed, Jul 2, 2008 at 3:07 PM, Daniel Drake wrote: > Hi, > > I'm working on updating OLPC's XO platform from Fedora 7 to Fedora 9. > This involves the addition/integration of ConsoleKit + PolicyKit into > HAL and other such components. The Sugar UI uses HAL to request > shutdown/reboot/USB mount/... > > Using ck-xinit-session we have successfully made ConsoleKit "aware" of > sugar, and under a normal boot we can shutdown the system (the default > HAL policy says that the active user can shutdown). > > However, if we hit ctrl+alt+F1 and login on the console, a 2nd session > is created, and we can no longer shutdown through sugar because the HAL > policy has the auth_admin requirement for the active user for shutting > down when multiple sessions are active (sugar doesn't interpret the > response and just silently fails to shut down). We'd like to fix this so > that shutting down from sugar works regardless of other sessions. > > The first option is to just modify the policies that are installed by > HAL, or modify the PolicyKit conf file to override the policies. But > those files are owned by packages so (I think) we would have to create > an OLPC-3 branch of those packages just to install the alternative > config file. Our main Fedora guy is working hard to cut down the number > of packages we have to branch, so I'm also considering other options. > > The second option is to implement an OLPC-specific simple authentication > agent. When sugar receives the dbus exception because it couldn't shut > down, it can interpret it and talk to an OLPC authentication agent for > authorisation. The OLPC auth agent would authorise all auth_admin > requests from the "olpc" user and deny everything else (no UI or > anything, just a straightforward accept/deny). Once sugar has obtained > authorisation it would then retry the shutdown and succeed. > > In your opinion(s), which of the above is the most sensible? > I guess the 2nd option is a little nicer in that it is generic. There > may be an increasing number of policies we have to override the > auth_admin requirement for in future, and the 2nd option covers all of > them. Another option might be to split the policy off as a separate (sub) package that you could then replace by a customized olpc policy. But having the outlined agent sounds like a good idea, too. From david at fubar.dk Wed Jul 2 17:48:17 2008 From: david at fubar.dk (David Zeuthen) Date: Wed, 02 Jul 2008 20:48:17 -0400 Subject: implementing an OLPC authentication agent In-Reply-To: <1215025629.2672.23.camel@olpc-desktop01.laptop.org> References: <1215025629.2672.23.camel@olpc-desktop01.laptop.org> Message-ID: <1215046097.3509.5.camel@x61.fubar.dk> On Wed, 2008-07-02 at 15:07 -0400, Daniel Drake wrote: > The first option is to just modify the policies that are installed by > HAL, or modify the PolicyKit conf file to override the policies. But > those files are owned by packages so (I think) we would have to create > an OLPC-3 branch of those packages just to install the alternative > config file. What about just using polkit-action to override the defaults? E.g. # polkit-action --set-defaults-active \ org.freedesktop.consolekit.system.stop-multiple-users \ yes You could do this in %post or similar of your installer. See http://hal.freedesktop.org/docs/PolicyKit/polkit-action.1.html for details. HTH, David From david at fubar.dk Wed Jul 2 17:51:08 2008 From: david at fubar.dk (David Zeuthen) Date: Wed, 02 Jul 2008 20:51:08 -0400 Subject: implementing an OLPC authentication agent In-Reply-To: <1215046097.3509.5.camel@x61.fubar.dk> References: <1215025629.2672.23.camel@olpc-desktop01.laptop.org> <1215046097.3509.5.camel@x61.fubar.dk> Message-ID: <1215046268.3509.7.camel@x61.fubar.dk> On Wed, 2008-07-02 at 20:48 -0400, David Zeuthen wrote: > What about just using polkit-action to override the defaults? E.g. > > # polkit-action --set-defaults-active \ > org.freedesktop.consolekit.system.stop-multiple-users \ > yes > > You could do this in %post or similar of your installer. See > > http://hal.freedesktop.org/docs/PolicyKit/polkit-action.1.html > > for details. Btw, I should also mention that this (of course) doesn't modify the .policy files; the overrides are stored in separate files. So you won't run into any problems on upgrades. Cheers, David From dsd at laptop.org Mon Jul 7 09:02:33 2008 From: dsd at laptop.org (Daniel Drake) Date: Mon, 07 Jul 2008 12:02:33 -0400 Subject: implementing an OLPC authentication agent In-Reply-To: <1215049052.3509.37.camel@x61.fubar.dk> References: <1215025629.2672.23.camel@olpc-desktop01.laptop.org> <1215046097.3509.5.camel@x61.fubar.dk> <1215046268.3509.7.camel@x61.fubar.dk> <818423da0807021829n62c83f98ob4179f19e7d26763@mail.gmail.com> <1215049052.3509.37.camel@x61.fubar.dk> Message-ID: <1215446553.2755.8.camel@olpc-desktop01.laptop.org> On Wed, 2008-07-02 at 21:37 -0400, David Zeuthen wrote: > On Wed, 2008-07-02 at 20:29 -0500, Daniel Drake wrote: > > Ah, excellent, I wasn't aware about this overrides method. > > I think the best option is for us to ship the overrides files in a separate > > package. Do you forsee any problems there? > > Yeah, if you ship the files in a package they're owned by that package. > Which means future overrides of the defaults by the user will > potentially get overwritten on updates. That's why you want to run it in > %post on each machine. > > Also, the location of these files is an implementation detail. Running > the command in %post hides this implementation detail from you. Ah, indeed. The user-overrides isn't really a concern for us, since all customisations outside of /home are wiped out during our (automatic) updates anyway. Plus we aren't really expecting users to mess with this. The location changing is a concern, but it's one we are happy to live with. Our policy package spec will have "Requires: /var/lib/PolicyKit-public" so any changes should become known quickly. Thanks, Daniel From david at fubar.dk Tue Jul 8 10:49:08 2008 From: david at fubar.dk (David Zeuthen) Date: Tue, 08 Jul 2008 13:49:08 -0400 Subject: Getting ready for PolicyKit 0.9 In-Reply-To: <1214855387.10476.30.camel@x61.fubar.dk> References: <1214855387.10476.30.camel@x61.fubar.dk> Message-ID: <1215539348.8169.14.camel@x61.fubar.dk> Michael? On Mon, 2008-06-30 at 15:49 -0400, David Zeuthen wrote: > Hey Michael (and mailing list), > > So I want to release PolicyKit 0.9 this week (not a lot of new features, > mainly bug fixes). A while back we had a private exchange where you > pointed out some minor (not security critical or anything) bugs in the > modes/permissions and the output text from configure. You also asked for > the rationale for these modes/permissions. > > I've finally corrected this with this commit: > > http://gitweb.freedesktop.org/?p=PolicyKit.git;a=commitdiff;h=785a63bcb175bc9eee14c664353e82c5ca8a6206 > > Does this look OK to you? > > Thanks, > David > > _______________________________________________ > polkit-devel mailing list > polkit-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/polkit-devel From harald at redhat.com Wed Jul 9 03:20:31 2008 From: harald at redhat.com (Harald Hoyer) Date: Wed, 09 Jul 2008 12:20:31 +0200 Subject: ANNOUNCE: pypolkit-0.1 released In-Reply-To: <200806191213.45844.bahadir@pardus.org.tr> References: <200806191213.45844.bahadir@pardus.org.tr> Message-ID: <487490EF.7080501@redhat.com> Bahad?r Kandemir wrote: > Hi, > > I'm happy to announce first release of PolicyKit Python binding, written by me > and Harald Hoyer. > > http://cekirdek.pardus.org.tr/~bahadir/polkit/pypolkit-0.1.tar.gz > > Cheers > > Any plans to integrate this into the main source? Otherwise, I would package it separately for Fedora. From mbiebl at gmail.com Wed Jul 9 12:57:09 2008 From: mbiebl at gmail.com (Michael Biebl) Date: Wed, 9 Jul 2008 21:57:09 +0200 Subject: Getting ready for PolicyKit 0.9 In-Reply-To: <1214855387.10476.30.camel@x61.fubar.dk> References: <1214855387.10476.30.camel@x61.fubar.dk> Message-ID: 2008/6/30 David Zeuthen : > > Hey Michael (and mailing list), > > So I want to release PolicyKit 0.9 this week (not a lot of new features, > mainly bug fixes). A while back we had a private exchange where you > pointed out some minor (not security critical or anything) bugs in the > modes/permissions and the output text from configure. You also asked for > the rationale for these modes/permissions. > > I've finally corrected this with this commit: > > http://gitweb.freedesktop.org/?p=PolicyKit.git;a=commitdiff;h=785a63bcb175bc9eee14c664353e82c5ca8a6206 > > Does this look OK to you? Hi David, thanks for looking into this. I checked the configure output, the installed files/directories and the README, and they all seem to be consistent now. The explanations in README are concise and well understandable. Nice work! On a completely different topic though: The error message, when CK doesn't return an active session, is suboptimal. Example: nm-connection-editor from NetworkManager 0.7 uses PolicyKit(-gnome) to modify system wide settings. If I kill the running console-kit-daemon instance (so ck-list-session returns nothing for the currently active user), I get the following error message (on the console) within nm-connection-editor: [WARN 21823] polkit-action.c:211:polkit_action_set_action_id(): polkit_action_validate_id (action_id) Not built with -rdynamic so unable to print a backtrace A normal user will not understand what the underlying problem is. Imho it would be much better, if polkit-gnome-manager would show an understandable error dialog, that the current user is not listed as being active, with the adive to check the ConsoleKit installation and logout/login again. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From david at fubar.dk Thu Jul 10 08:35:52 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 10 Jul 2008 11:35:52 -0400 Subject: ANNOUNCE: pypolkit-0.1 released In-Reply-To: <487490EF.7080501@redhat.com> References: <200806191213.45844.bahadir@pardus.org.tr> <487490EF.7080501@redhat.com> Message-ID: <1215704152.3448.8.camel@x61.fubar.dk> On Wed, 2008-07-09 at 12:20 +0200, Harald Hoyer wrote: > Bahad?r Kandemir wrote: > > Hi, > > > > I'm happy to announce first release of PolicyKit Python binding, written by me > > and Harald Hoyer. > > > > http://cekirdek.pardus.org.tr/~bahadir/polkit/pypolkit-0.1.tar.gz > > > > Cheers > > > > > > Any plans to integrate this into the main source? Yeah, sounds like a good idea. I'll include it in 0.9 which I'll roll next week (will do a RC tarball too). Thanks, David From david at fubar.dk Thu Jul 10 08:37:14 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 10 Jul 2008 11:37:14 -0400 Subject: Getting ready for PolicyKit 0.9 In-Reply-To: References: <1214855387.10476.30.camel@x61.fubar.dk> Message-ID: <1215704234.3448.10.camel@x61.fubar.dk> On Wed, 2008-07-09 at 21:57 +0200, Michael Biebl wrote: > I checked the configure output, the installed files/directories and > the README, and they all seem to be consistent now. The explanations > in README are concise and well understandable. Nice work! Great, thanks for looking through this. I appreciate it. > On a completely different topic though: > The error message, when CK doesn't return an active session, is suboptimal. > Example: nm-connection-editor from NetworkManager 0.7 uses > PolicyKit(-gnome) to modify system wide settings. If I kill the > running console-kit-daemon instance (so ck-list-session returns > nothing for the currently active user), I get the following error > message (on the console) within nm-connection-editor: > > [WARN 21823] polkit-action.c:211:polkit_action_set_action_id(): > polkit_action_validate_id (action_id) > Not built with -rdynamic so unable to print a backtrace > > A normal user will not understand what the underlying problem is. > > Imho it would be much better, if polkit-gnome-manager would show an > understandable error dialog, that the current user is not listed as > being active, with the adive to check the ConsoleKit installation and > logout/login again. Yeah, in general error messages should be more friendly so patches welcome for that. However, it would be very weird if the CK daemon wasn't running (your example includes killing it - why would you want to do that?) Thanks, David From mbiebl at gmail.com Thu Jul 10 08:55:08 2008 From: mbiebl at gmail.com (Michael Biebl) Date: Thu, 10 Jul 2008 17:55:08 +0200 Subject: Getting ready for PolicyKit 0.9 In-Reply-To: <1215704234.3448.10.camel@x61.fubar.dk> References: <1214855387.10476.30.camel@x61.fubar.dk> <1215704234.3448.10.camel@x61.fubar.dk> Message-ID: 2008/7/10 David Zeuthen : > On Wed, 2008-07-09 at 21:57 +0200, Michael Biebl wrote: >> On a completely different topic though: >> The error message, when CK doesn't return an active session, is suboptimal. >> Example: nm-connection-editor from NetworkManager 0.7 uses >> PolicyKit(-gnome) to modify system wide settings. If I kill the >> running console-kit-daemon instance (so ck-list-session returns >> nothing for the currently active user), I get the following error >> message (on the console) within nm-connection-editor: >> >> [WARN 21823] polkit-action.c:211:polkit_action_set_action_id(): >> polkit_action_validate_id (action_id) >> Not built with -rdynamic so unable to print a backtrace >> >> A normal user will not understand what the underlying problem is. >> >> Imho it would be much better, if polkit-gnome-manager would show an >> understandable error dialog, that the current user is not listed as >> being active, with the adive to check the ConsoleKit installation and >> logout/login again. > > Yeah, in general error messages should be more friendly so patches > welcome for that. However, it would be very weird if the CK daemon > wasn't running (your example includes killing it - why would you want to > do that?) - What if CK/PK is installed when the user is already logged in - Security updates of dbus or CK might make it necessary to restart those services (and CK will quit as soon as dbus is restarted). Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From david at fubar.dk Thu Jul 10 09:19:41 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 10 Jul 2008 12:19:41 -0400 Subject: Getting ready for PolicyKit 0.9 In-Reply-To: References: <1214855387.10476.30.camel@x61.fubar.dk> <1215704234.3448.10.camel@x61.fubar.dk> Message-ID: <1215706781.3448.28.camel@x61.fubar.dk> Hey Michael, Reviving an old discussion heh? ;-) On Thu, 2008-07-10 at 17:55 +0200, Michael Biebl wrote: > > Yeah, in general error messages should be more friendly so patches > > welcome for that. However, it would be very weird if the CK daemon > > wasn't running (your example includes killing it - why would you want to > > do that?) > > - What if CK/PK is installed when the user is already logged in I consider this (tracking login sessions and providing authorization services) core parts of the OS. So you want these installed and running up front. Or you want to ask the user to login/logout (or reboot) if your OS allows people what to install without these components. > - Security updates of dbus or CK might make it necessary to restart > those services (and CK will quit as soon as dbus is restarted). The usual answer: reboot. Or for the more adventuresome: write a patch to make ConsoleKit and the system bus daemon transfer state to the new instance just like e.g. init(1) does. And get those patches past the maintainers. (Seriously: the Linux kernel sees far more security updates than CK and D-Bus and I suspect you can't get patches into the kernel to allow kexec'ing into a new kernel retaining all state.) David From david at fubar.dk Tue Jul 15 11:38:48 2008 From: david at fubar.dk (David Zeuthen) Date: Tue, 15 Jul 2008 14:38:48 -0400 Subject: Question - PolicyKit In-Reply-To: <487A8D6E.6050400@Gmail.com> References: <487A8D6E.6050400@Gmail.com> Message-ID: <1216147128.8536.12.camel@x61.fubar.dk> Hi dawg, Your mail is definitely off-topic for xdg-list so I'm moving it to http://lists.freedesktop.org/mailman/listinfo/polkit-devel On Sun, 2008-07-13 at 19:19 -0400, dawg wrote: > One thing which has really annoyed me since PolicyKit was introduced > to Fedora is that the dialog has "Remember authorization" checked by > default. In and of itself, not a HUGE deal, but it does not remember > the option you select, so if you choose NOT to remember authorization, > you have to be careful to uncheck that option every single time. Maybe you're one of those people that buy into the fallacy that the more password dialogs the better. Keep in mind that only in very exceptional cases (such as installing untrusted software or dialing a telephone that might cost $50 / minute) it makes sense to interrupt the user with a password dialog to make him prove he's either a) human; or b) an administrator; before initiating the action. Here's the thing: password dialogs only slow down users; ideally users will have the authorizations they need to get work done without running into annoying password dialogs. Of course in a general purpose OS without any administrator (e.g. most consumer systems) we (meaning the OS vendor) can't just give people authorizations because we don't know in what way the installed OS will be used. So that's why we put up password dialogs to make the user prove that he's either a) human; or b) an administrator; before we allow certain actions. And we allow the user (in some cases) to retain the authorization so they won't be interrupted by the password dialog again. So think of most of these password dialogs as a way to bootstrap the system; it's the best we can do if there's no administrator to grant authorizations before the users start using the machine. > So optimally, you'd hope for it to remember your last selection, but > even if that were not implemented, you'd hope the default made more > sense - i.e. why would the default be to opt-in? If you do opt in, you > never see that dialog again anyway, so you wouldn't need to worry > about changing the option except the first time you see it. On the > other hand, if you do not want to remember authorization, you have to > switch from the default EVERY time or your settings will be changed. > > Is there a way to configure the default option checked for the > PolicyKit dialog? No but do try to read the polkit-action and polkit-auth man pages. For example # polkit-action --set-defaults-active \ org.freedesktop.hal.storage.mount-fixed \ auth_admin will never allow active sessions on the local console to retain authorizations for mounting fixed disks (e.g. the check boxes are never shown). David From david at fubar.dk Tue Jul 15 12:26:04 2008 From: david at fubar.dk (David Zeuthen) Date: Tue, 15 Jul 2008 15:26:04 -0400 Subject: Question - PolicyKit In-Reply-To: <487CF41F.8070208@Gmail.com> References: <487A8D6E.6050400@Gmail.com> <1216147128.8536.12.camel@x61.fubar.dk> <487CF41F.8070208@Gmail.com> Message-ID: <1216149964.8536.29.camel@x61.fubar.dk> On Tue, 2008-07-15 at 15:01 -0400, dawg wrote: > Sorry, I'm a lost pooch. But anyway... > > No, I don't buy into that, but I do not want to allow all things to be > accessible without a password. There are reasons for those dialogs, or > they wouldn't exist. Not everyone wants to allow anyone to access > everything. And if the expectation is that no one should need or want > the dialog, why not change PolicyKit so that it doesn't ask at all? By > your logic, it should all just be assumed, without ever even giving > the dialog with the stupid default. Uh, that's why you can change the defaults as I explained in the earlier mail. See, the defaults are chosen by the application developer. Of course some administrators will want to change them. So we provide a mechanism (e.g. polkit-action(1)) to do exactly that. > The only problem with the dialog is that you slow down ADMINISTRATORS > by making them uncheck the default every time (and even more so if > they forget once and then have to fix it through some other dialog). > If the "human" or administrator wishes for the authorization to be > remembered, they should have to check the box to remember -- because > they would only have to do it once! They wouldn't see the dialog > again. On the other hand, if the administrator does not want the info > to be remembered, he or she will have to uncheck the option every > single time. Keep in mind that some actions does not come with a "remember authorization" check box at all. For example $ polkit-action --action org.freedesktop.packagekit.localinstall-untrusted action_id: org.freedesktop.packagekit.localinstall-untrusted description: Install untrusted local file message: Further authentication is required to install an untrusted local file default_any: no default_inactive: no default_active: auth_admin doesn't. It's up to the application developer to choose whether the authorization. Now, if you as an administrator disagrees with the upstream developer simply change the default using polkit-action(1). And if you think, for whatever reason, that the upstream developer should change it upstream go talk to him. Try to convince him that it doesn't make sense users should retain the authorization. I bet in most cases the upstream developer will reject such a feature request simply because it doesn't make sense to ask for passwords for such mundane things as mounting a disk, installing a signed trusted RPM etc. etc. in a consumer style setting where the user is sitting right in front of the system. Think about it. You're asking for a default where the "keep authorization" check box is to be unchecked when the dialog comes up. That's a terrible default since most people won't read the dialog as you point out yourself. So the result is that people will keep being interrupted by password dialogs. Which sucks. > I don't mean to sound like an arrogant ass, but I do not understand > how you can't see the point I'm trying to make. The only thing I can > possibly think of is that you are assuming the administrator is a > separate account or something...? Sure, that may be the case, but > there are many situations in which the admin would want to perform an > action without logging out the current user or taking the TIME to log > in to a second account or use the command line or whatnot ever else. Maybe if you could come up with concrete examples of what problems you have it would be useful, e.g. in what polkit authentication dialogs (need the action name, see Details> in the dialog) do you run into where you wish the "retain authorization" checkbox wasn't clicked by default? (also, please avoid HTML mail and please reply inline, e.g. no top posting. Thanks.) David From dirTdogE at Gmail.com Tue Jul 15 12:01:51 2008 From: dirTdogE at Gmail.com (dawg) Date: Tue, 15 Jul 2008 15:01:51 -0400 Subject: Question - PolicyKit In-Reply-To: <1216147128.8536.12.camel@x61.fubar.dk> References: <487A8D6E.6050400@Gmail.com> <1216147128.8536.12.camel@x61.fubar.dk> Message-ID: <487CF41F.8070208@Gmail.com> Sorry, I'm a lost pooch. But anyway... No, I don't buy into that, but I do not want to allow all things to be accessible without a password. There are reasons for those dialogs, or they wouldn't exist. Not everyone wants to allow anyone to access everything. And if the expectation is that no one should need or want the dialog, why not change PolicyKit so that it doesn't ask at all? By your logic, it should all just be assumed, without ever even giving the dialog with the stupid default. The only problem with the dialog is that you slow down ADMINISTRATORS by making them uncheck the default _every_ time (and even more so if they forget once and then have to fix it through some other dialog). If the "human" or administrator wishes for the authorization to be remembered, they should have to check the box to remember -- because they would only have to do it once! They wouldn't see the dialog again. On the other hand, if the administrator does not want the info to be remembered, he or she will have to uncheck the option every single time. I don't mean to sound like an arrogant ass, but I do not understand how you can't see the point I'm trying to make. The only thing I can possibly think of is that you are assuming the administrator is a separate account or something...? Sure, that may be the case, but there are many situations in which the admin would want to perform an action without logging out the current user or taking the TIME to log in to a second account or use the command line or whatnot ever else. Best Regards, Nate David Zeuthen wrote: > Hi dawg, > > Your mail is definitely off-topic for xdg-list so I'm moving it to > > http://lists.freedesktop.org/mailman/listinfo/polkit-devel > > On Sun, 2008-07-13 at 19:19 -0400, dawg wrote: > >> One thing which has really annoyed me since PolicyKit was introduced >> to Fedora is that the dialog has "Remember authorization" checked by >> default. In and of itself, not a HUGE deal, but it does not remember >> the option you select, so if you choose NOT to remember authorization, >> you have to be careful to uncheck that option every single time. >> > > Maybe you're one of those people that buy into the fallacy that the more > password dialogs the better. > > Keep in mind that only in very exceptional cases (such as installing > untrusted software or dialing a telephone that might cost $50 / minute) > it makes sense to interrupt the user with a password dialog to make him > prove he's either a) human; or b) an administrator; before initiating > the action. > > Here's the thing: password dialogs only slow down users; ideally users > will have the authorizations they need to get work done without running > into annoying password dialogs. > > Of course in a general purpose OS without any administrator (e.g. most > consumer systems) we (meaning the OS vendor) can't just give people > authorizations because we don't know in what way the installed OS will > be used. So that's why we put up password dialogs to make the user prove > that he's either a) human; or b) an administrator; before we allow > certain actions. And we allow the user (in some cases) to retain the > authorization so they won't be interrupted by the password dialog again. > > So think of most of these password dialogs as a way to bootstrap the > system; it's the best we can do if there's no administrator to grant > authorizations before the users start using the machine. > > >> So optimally, you'd hope for it to remember your last selection, but >> even if that were not implemented, you'd hope the default made more >> sense - i.e. why would the default be to opt-in? If you do opt in, you >> never see that dialog again anyway, so you wouldn't need to worry >> about changing the option except the first time you see it. On the >> other hand, if you do not want to remember authorization, you have to >> switch from the default EVERY time or your settings will be changed. >> >> Is there a way to configure the default option checked for the >> PolicyKit dialog? >> > > No but do try to read the polkit-action and polkit-auth man pages. For > example > > # polkit-action --set-defaults-active \ > org.freedesktop.hal.storage.mount-fixed \ > auth_admin > > will never allow active sessions on the local console to retain > authorizations for mounting fixed disks (e.g. the check boxes are never > shown). > > David > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freedesktop.org/archives/polkit-devel/attachments/20080715/9c4b56b0/attachment.htm From dirTdogE at Gmail.com Tue Jul 15 13:20:41 2008 From: dirTdogE at Gmail.com (dawg) Date: Tue, 15 Jul 2008 16:20:41 -0400 Subject: Question - PolicyKit In-Reply-To: <1216149964.8536.29.camel@x61.fubar.dk> References: <487A8D6E.6050400@Gmail.com> <1216147128.8536.12.camel@x61.fubar.dk> <487CF41F.8070208@Gmail.com> <1216149964.8536.29.camel@x61.fubar.dk> Message-ID: <487D0699.4080905@Gmail.com> David Zeuthen wrote: > On Tue, 2008-07-15 at 15:01 -0400, dawg wrote: > >> Sorry, I'm a lost pooch. But anyway... >> >> No, I don't buy into that, but I do not want to allow all things to be >> accessible without a password. There are reasons for those dialogs, or >> they wouldn't exist. Not everyone wants to allow anyone to access >> everything. And if the expectation is that no one should need or want >> the dialog, why not change PolicyKit so that it doesn't ask at all? By >> your logic, it should all just be assumed, without ever even giving >> the dialog with the stupid default. >> > > Uh, that's why you can change the defaults as I explained in the earlier > mail. See, the defaults are chosen by the application developer. Of > course some administrators will want to change them. So we provide a > mechanism (e.g. polkit-action(1)) to do exactly that. > I may have misunderstood you. Changing the default for the checkbox is exactly what I want to do. It sounded like you were stating that it was only possible to make it so that the "remember" option is *never* shown (not what I want). > >> The only problem with the dialog is that you slow down ADMINISTRATORS >> by making them uncheck the default every time (and even more so if >> they forget once and then have to fix it through some other dialog). >> If the "human" or administrator wishes for the authorization to be >> remembered, they should have to check the box to remember -- because >> they would only have to do it once! They wouldn't see the dialog >> again. On the other hand, if the administrator does not want the info >> to be remembered, he or she will have to uncheck the option every >> single time. >> > > Keep in mind that some actions does not come with a "remember > authorization" check box at all. For example > > $ polkit-action --action org.freedesktop.packagekit.localinstall-untrusted > action_id: org.freedesktop.packagekit.localinstall-untrusted > description: Install untrusted local file > message: Further authentication is required to install an untrusted local file > default_any: no > default_inactive: no > default_active: auth_admin > > doesn't. > > It's up to the application developer to choose whether the > authorization. Now, if you as an administrator disagrees with the > upstream developer simply change the default using polkit-action(1). And > if you think, for whatever reason, that the upstream developer should > change it upstream go talk to him. Try to convince him that it doesn't > make sense users should retain the authorization. > I was not saying that it doesn't make sense to allow them to retain authorization (I *want* it to in some cases), I am only saying it doesn't make sense for the checkbox to be ticked by default if it doesn't remember that it was unchecked in previous instances. > I bet in most cases the upstream developer will reject such a feature > request simply because it doesn't make sense to ask for passwords for > such mundane things as mounting a disk, installing a signed trusted RPM > etc. etc. in a consumer style setting where the user is sitting right in > front of the system. > I agree that it doesn't make sense to ask for passwords for mounting disks (in most cases). (Of course it makes perfect sense in certain secure environments.) I happily let PolicyKit retain that authorization. However, for example, I do *not* want a user to be able to uninstall whatever they want. My family is not as familiar with Linux as I am (indeed, I've completely broken my system by mistake while uninstalling things in the past), but more to the point, someone could uninstall security software such as firewalls, etc., which certainly is a security concern. It might not even be the end user -- they might simply walk away from their station at work or whatnot ever else. > Think about it. You're asking for a default where the "keep > authorization" check box is to be unchecked when the dialog comes up. > That's a terrible default since most people won't read the dialog as you > point out yourself. So the result is that people will keep being > interrupted by password dialogs. Which sucks. > I did not say that most people wouldn't read the dialog. But you are right, people don't read it if they see it all of the time. If the checkbox was not defaulted to ticked (as I am suggesting), the worst case scenario (with regard to the point you are making) is that some stupid users may never bother to change the option. So what? It would be their own fault, and, arguably, they would probably eventually notice the option. Besides, most people are familiar with the idea of checking a box to remember their password if they use the Web on a regular basis. On the other hand, if the user does not read the dialog and the default is checked, they will have unwittingly changed a security setting on their computer! And you are saying the former is worse? > >> I don't mean to sound like an arrogant ass, but I do not understand >> how you can't see the point I'm trying to make. The only thing I can >> possibly think of is that you are assuming the administrator is a >> separate account or something...? Sure, that may be the case, but >> there are many situations in which the admin would want to perform an >> action without logging out the current user or taking the TIME to log >> in to a second account or use the command line or whatnot ever else. >> > > Maybe if you could come up with concrete examples of what problems you > have it would be useful, e.g. in what polkit authentication dialogs > (need the action name, see Details> in the dialog) do you run into where > you wish the "retain authorization" checkbox wasn't clicked by default? > I don't want users (for example) to be able to uninstall programs which are needed for system stability, security, or so on. I'm sorry, I do not understand what question or statement you are making in parenthesis above... > (also, please avoid HTML mail and please reply inline, e.g. no top > posting. Thanks.) > Sorry. I believe I've switched to plain text in this message. > David > Nate > > > > From david at fubar.dk Wed Jul 16 10:37:40 2008 From: david at fubar.dk (David Zeuthen) Date: Wed, 16 Jul 2008 13:37:40 -0400 Subject: Question - PolicyKit In-Reply-To: <487D0699.4080905@Gmail.com> References: <487A8D6E.6050400@Gmail.com> <1216147128.8536.12.camel@x61.fubar.dk> <487CF41F.8070208@Gmail.com> <1216149964.8536.29.camel@x61.fubar.dk> <487D0699.4080905@Gmail.com> Message-ID: <1216229860.3329.29.camel@x61.fubar.dk> On Tue, 2008-07-15 at 16:20 -0400, dawg wrote: > > Uh, that's why you can change the defaults as I explained in the earlier > > mail. See, the defaults are chosen by the application developer. Of > > course some administrators will want to change them. So we provide a > > mechanism (e.g. polkit-action(1)) to do exactly that. > > > I may have misunderstood you. Changing the default for the checkbox is > exactly what I want to do. It sounded like you were stating that it was > only possible to make it so that the "remember" option is *never* shown > (not what I want). No, I'm talking about changing the defaults for an action; e.g. if the default is auth_[self|admin] -> no checkboxes http://hal.freedesktop.org/docs/PolicyKit-gnome/auth-self.png auth_[self|admin]_keep_session -> a single checkbox http://hal.freedesktop.org/docs/PolicyKit-gnome/auth-retain-session.png auth_[self|admin]_keep_always -> two checkboxes http://hal.freedesktop.org/docs/PolicyKit-gnome/auth-retain-always.png > I was not saying that it doesn't make sense to allow them to retain > authorization (I *want* it to in some cases), I am only saying it > doesn't make sense for the checkbox to be ticked by default if it > doesn't remember that it was unchecked in previous instances. This doesn't make sense; either you want people to retain an authorization or you don't. If you don't simply change the defaults with the polkit-action(1) command line tool or the GNOME tool http://people.freedesktop.org/~david/polkit-gnome-authorizations.png Again, not checking the box when the dialog comes up is a _terrible_ default. The whole *idea* behind retaining authorizations is that it's a boot-strap mechanism to let users accumulate authorizations. Which is exactly what you want on a system without administrators (e.g. consumer systems). (as a side note: how to do this on set of managed systems using a directory server using roles is something I'm planning to add pretty soon; basically FreeIPA integration in PolicyKit. But more about that later.) > I happily let PolicyKit retain that authorization. > However, for example, I do *not* want a user to be able to uninstall > whatever they want. My family is not as familiar with Linux as I am > (indeed, I've completely broken my system by mistake while uninstalling > things in the past), but more to the point, someone could uninstall > security software such as firewalls, etc., which certainly is a security > concern. It might not even be the end user -- they might simply walk > away from their station at work or whatnot ever else. So it would probably make sense to ask the PackageKit developers for a separate PolicyKit action for uninstalling packages. Suggest that you ask for that. Then when such an action is available you can simply change the defaults such that the authorization can't be retained. Oh, what do you know, it looks like it's there already $ polkit-action --action org.freedesktop.packagekit.remove action_id: org.freedesktop.packagekit.remove description: Remove package message: Authentication is required to remove packages default_any: no default_inactive: no default_active: auth_admin_keep_always So simply do this as root polkit-action --set-defaults-active org.freedesktop.packagekit.remove auth_admin and you're good to go. Or use the UI. You can use polkit-gnome-authorizations to easily scrub this authorizations from other users (check the "[x] Show authorizations from all users" check box, then use the "Revoke" button to revoke the authorizations.) Does these steps solve the basic problem for you? > On the other hand, if the user does not read the dialog and the default > is checked, they will have unwittingly changed a security setting on > their computer! And you are saying the former is worse? No, this is perfectly fine. If the so-called "security setting" had to do with an exploitable vector (e.g. retaining an authorization to install unsigned software) it would be a _bug_ if the default allowed the user to retain the authorization. > > Maybe if you could come up with concrete examples of what problems you > > have it would be useful, e.g. in what polkit authentication dialogs > > (need the action name, see Details> in the dialog) do you run into where > > you wish the "retain authorization" checkbox wasn't clicked by default? > > > I don't want users (for example) to be able to uninstall programs which > are needed for system stability, security, or so on. See above. David From dirTdogE at Gmail.com Wed Jul 16 10:43:22 2008 From: dirTdogE at Gmail.com (dawg) Date: Wed, 16 Jul 2008 13:43:22 -0400 Subject: Question - PolicyKit In-Reply-To: <1216229860.3329.29.camel@x61.fubar.dk> References: <487A8D6E.6050400@Gmail.com> <1216147128.8536.12.camel@x61.fubar.dk> <487CF41F.8070208@Gmail.com> <1216149964.8536.29.camel@x61.fubar.dk> <487D0699.4080905@Gmail.com> <1216229860.3329.29.camel@x61.fubar.dk> Message-ID: <487E333A.4010300@Gmail.com> This discussion is pointless. Thank you for your time. Best Regards, Nate David Zeuthen wrote: > On Tue, 2008-07-15 at 16:20 -0400, dawg wrote: > >>> Uh, that's why you can change the defaults as I explained in the earlier >>> mail. See, the defaults are chosen by the application developer. Of >>> course some administrators will want to change them. So we provide a >>> mechanism (e.g. polkit-action(1)) to do exactly that. >>> >>> >> I may have misunderstood you. Changing the default for the checkbox is >> exactly what I want to do. It sounded like you were stating that it was >> only possible to make it so that the "remember" option is *never* shown >> (not what I want). >> > > No, I'm talking about changing the defaults for an action; e.g. if the > default is > > auth_[self|admin] -> no checkboxes > http://hal.freedesktop.org/docs/PolicyKit-gnome/auth-self.png > > auth_[self|admin]_keep_session -> a single checkbox > http://hal.freedesktop.org/docs/PolicyKit-gnome/auth-retain-session.png > > auth_[self|admin]_keep_always -> two checkboxes > http://hal.freedesktop.org/docs/PolicyKit-gnome/auth-retain-always.png > > >> I was not saying that it doesn't make sense to allow them to retain >> authorization (I *want* it to in some cases), I am only saying it >> doesn't make sense for the checkbox to be ticked by default if it >> doesn't remember that it was unchecked in previous instances. >> > > This doesn't make sense; either you want people to retain an > authorization or you don't. If you don't simply change the defaults with > the polkit-action(1) command line tool or the GNOME tool > > http://people.freedesktop.org/~david/polkit-gnome-authorizations.png > > Again, not checking the box when the dialog comes up is a _terrible_ > default. The whole *idea* behind retaining authorizations is that it's a > boot-strap mechanism to let users accumulate authorizations. Which is > exactly what you want on a system without administrators (e.g. consumer > systems). > > (as a side note: how to do this on set of managed systems using a > directory server using roles is something I'm planning to add pretty > soon; basically FreeIPA integration in PolicyKit. But more about that > later.) > > >> I happily let PolicyKit retain that authorization. >> However, for example, I do *not* want a user to be able to uninstall >> whatever they want. My family is not as familiar with Linux as I am >> (indeed, I've completely broken my system by mistake while uninstalling >> things in the past), but more to the point, someone could uninstall >> security software such as firewalls, etc., which certainly is a security >> concern. It might not even be the end user -- they might simply walk >> away from their station at work or whatnot ever else. >> > > So it would probably make sense to ask the PackageKit developers for a > separate PolicyKit action for uninstalling packages. Suggest that you > ask for that. Then when such an action is available you can simply > change the defaults such that the authorization can't be retained. > > Oh, what do you know, it looks like it's there already > > $ polkit-action --action org.freedesktop.packagekit.remove > action_id: org.freedesktop.packagekit.remove > description: Remove package > message: Authentication is required to remove packages > default_any: no > default_inactive: no > default_active: auth_admin_keep_always > > So simply do this as root > > polkit-action --set-defaults-active org.freedesktop.packagekit.remove auth_admin > > and you're good to go. Or use the UI. You can use > polkit-gnome-authorizations to easily scrub this authorizations from > other users (check the "[x] Show authorizations from all users" check > box, then use the "Revoke" button to revoke the authorizations.) > > Does these steps solve the basic problem for you? > > >> On the other hand, if the user does not read the dialog and the default >> is checked, they will have unwittingly changed a security setting on >> their computer! And you are saying the former is worse? >> > > No, this is perfectly fine. If the so-called "security setting" had to > do with an exploitable vector (e.g. retaining an authorization to > install unsigned software) it would be a _bug_ if the default allowed > the user to retain the authorization. > > >>> Maybe if you could come up with concrete examples of what problems you >>> have it would be useful, e.g. in what polkit authentication dialogs >>> (need the action name, see Details> in the dialog) do you run into where >>> you wish the "retain authorization" checkbox wasn't clicked by default? >>> >>> >> I don't want users (for example) to be able to uninstall programs which >> are needed for system stability, security, or so on. >> > > See above. > > David > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freedesktop.org/archives/polkit-devel/attachments/20080716/f39c9416/attachment.htm From sgallagh at redhat.com Wed Jul 16 10:43:23 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 16 Jul 2008 13:43:23 -0400 Subject: Question - PolicyKit In-Reply-To: <1216229860.3329.29.camel@x61.fubar.dk> References: <487A8D6E.6050400@Gmail.com> <1216147128.8536.12.camel@x61.fubar.dk> <487CF41F.8070208@Gmail.com> <1216149964.8536.29.camel@x61.fubar.dk> <487D0699.4080905@Gmail.com> <1216229860.3329.29.camel@x61.fubar.dk> Message-ID: <487E333B.1030206@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Zeuthen wrote: > On Tue, 2008-07-15 at 16:20 -0400, dawg wrote: >>> Uh, that's why you can change the defaults as I explained in the earlier >>> mail. See, the defaults are chosen by the application developer. Of >>> course some administrators will want to change them. So we provide a >>> mechanism (e.g. polkit-action(1)) to do exactly that. >>> >> I may have misunderstood you. Changing the default for the checkbox is >> exactly what I want to do. It sounded like you were stating that it was >> only possible to make it so that the "remember" option is *never* shown >> (not what I want). > > No, I'm talking about changing the defaults for an action; e.g. if the > default is > > auth_[self|admin] -> no checkboxes > http://hal.freedesktop.org/docs/PolicyKit-gnome/auth-self.png > > auth_[self|admin]_keep_session -> a single checkbox > http://hal.freedesktop.org/docs/PolicyKit-gnome/auth-retain-session.png > > auth_[self|admin]_keep_always -> two checkboxes > http://hal.freedesktop.org/docs/PolicyKit-gnome/auth-retain-always.png > >> I was not saying that it doesn't make sense to allow them to retain >> authorization (I *want* it to in some cases), I am only saying it >> doesn't make sense for the checkbox to be ticked by default if it >> doesn't remember that it was unchecked in previous instances. > > This doesn't make sense; either you want people to retain an > authorization or you don't. If you don't simply change the defaults with > the polkit-action(1) command line tool or the GNOME tool > > http://people.freedesktop.org/~david/polkit-gnome-authorizations.png > > Again, not checking the box when the dialog comes up is a _terrible_ > default. The whole *idea* behind retaining authorizations is that it's a > boot-strap mechanism to let users accumulate authorizations. Which is > exactly what you want on a system without administrators (e.g. consumer > systems). > > (as a side note: how to do this on set of managed systems using a > directory server using roles is something I'm planning to add pretty > soon; basically FreeIPA integration in PolicyKit. But more about that > later.) > David, what about simply storing the fact that, the last time through, the user opted to uncheck that box. If they have done so once, retain that state for future authorization requests until they manually check it again. This would avoid the situation dawg described where a user has to actively choose to remove the checkbox each and every time. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh+MzsACgkQc7MaxVic+2rl4wCdHemkekdqFx481Iz4KvPkFzJf dnIAnRYOmizN2xouGta73rIekzjMs7Bo =NYBQ -----END PGP SIGNATURE----- From mbiebl at gmail.com Wed Jul 16 11:06:24 2008 From: mbiebl at gmail.com (Michael Biebl) Date: Wed, 16 Jul 2008 20:06:24 +0200 Subject: Question - PolicyKit In-Reply-To: <487E333B.1030206@redhat.com> References: <487A8D6E.6050400@Gmail.com> <1216147128.8536.12.camel@x61.fubar.dk> <487CF41F.8070208@Gmail.com> <1216149964.8536.29.camel@x61.fubar.dk> <487D0699.4080905@Gmail.com> <1216229860.3329.29.camel@x61.fubar.dk> <487E333B.1030206@redhat.com> Message-ID: 2008/7/16 Stephen Gallagher : > > David, what about simply storing the fact that, the last time through, > the user opted to uncheck that box. If they have done so once, retain > that state for future authorization requests until they manually check > it again. This would avoid the situation dawg described where a user has > to actively choose to remove the checkbox each and every time. TBH, I thought this is exactly the feature dawg was requesting (and I admit that I think it would be useful). Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From dirTdogE at Gmail.com Wed Jul 16 11:18:07 2008 From: dirTdogE at Gmail.com (dawg) Date: Wed, 16 Jul 2008 14:18:07 -0400 Subject: Question - PolicyKit In-Reply-To: References: <487A8D6E.6050400@Gmail.com> <1216147128.8536.12.camel@x61.fubar.dk> <487CF41F.8070208@Gmail.com> <1216149964.8536.29.camel@x61.fubar.dk> <487D0699.4080905@Gmail.com> <1216229860.3329.29.camel@x61.fubar.dk> <487E333B.1030206@redhat.com> Message-ID: <487E3B5F.6090808@Gmail.com> Michael Biebl wrote: > 2008/7/16 Stephen Gallagher : > >> David, what about simply storing the fact that, the last time through, >> the user opted to uncheck that box. If they have done so once, retain >> that state for future authorization requests until they manually check >> it again. This would avoid the situation dawg described where a user has >> to actively choose to remove the checkbox each and every time. >> > > TBH, I thought this is exactly the feature dawg was requesting (and I > admit that I think it would be useful). > To clarify, that was indeed the solution I had suggested as "optimal" in my original message. Either remembering the user's selection or changing to a more sensible default (more sensible in the case that the dialog does NOT remember the user's selection) would fully address the issue which I was describing. > Cheers, > Michael > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freedesktop.org/archives/polkit-devel/attachments/20080716/1bde7253/attachment.html From ktdann at gmail.com Wed Jul 16 19:55:11 2008 From: ktdann at gmail.com (Daniel) Date: Thu, 17 Jul 2008 11:55:11 +0900 Subject: Problem compiling latest copy of policykit Message-ID: <9b7ca6570807161955l108d89bcib082cd10b0a5775@mail.gmail.com> Hi there, I've checked out the latest copy of policykit by running, below command. # git clone git://anongit.freedesktop.org/git/PolicyKit After that, I've ran "autogen.sh", followed by "configure" configure, first complained that I needed intltoolize utility greater than 0.36.0 So, I got a copy 0.36.3 off the net and completed configure successfully. However, during 'make', it fails with below error. make[2]: Leaving directory `/home//build/src/tmp1/PolicyKit/tools' Making all in policy make[2]: Entering directory `/home//build/src/tmp1/PolicyKit/policy' Makefile:429: *** missing separator. Stop. make[2]: Leaving directory `/home//build/src/tmp1/PolicyKit/policy' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home//build/src/tmp1/PolicyKit' make: *** [all] Error 2 Here is a cut out of policy/Makefile, Line number 429 @INTLTOOL_POLICY_RULE@ I can see the problem. It's with intltool. It's meant to substitute that line, but it's not doing it. After googling for a while, I found a comment that I should use intltool version 0.37.1 So, naturally I followed that recommendation. But, even then, make still fails with same error. FYI, I tried with the latest copy of intltool. That is 0.40.0 This version of intltool no longer generates "intltool-update.in" and few others that is needed by PolicyKit. However, even getting around that problem, I still failed 'make' with same error. What am I doing wrong? Thank you in advance. -- Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freedesktop.org/archives/polkit-devel/attachments/20080717/ef0e18f7/attachment.html From david at fubar.dk Fri Jul 18 07:07:31 2008 From: david at fubar.dk (David Zeuthen) Date: Fri, 18 Jul 2008 10:07:31 -0400 Subject: Question - PolicyKit In-Reply-To: References: <487A8D6E.6050400@Gmail.com> <1216147128.8536.12.camel@x61.fubar.dk> <487CF41F.8070208@Gmail.com> <1216149964.8536.29.camel@x61.fubar.dk> <487D0699.4080905@Gmail.com> <1216229860.3329.29.camel@x61.fubar.dk> <487E333B.1030206@redhat.com> Message-ID: <1216390051.11594.2.camel@x61.fubar.dk> On Wed, 2008-07-16 at 20:06 +0200, Michael Biebl wrote: > 2008/7/16 Stephen Gallagher : > > > > David, what about simply storing the fact that, the last time through, > > the user opted to uncheck that box. If they have done so once, retain > > that state for future authorization requests until they manually check > > it again. This would avoid the situation dawg described where a user has > > to actively choose to remove the checkbox each and every time. > > TBH, I thought this is exactly the feature dawg was requesting (and I > admit that I think it would be useful). OK, I've committed the attached patch that does this. It also includes a boolean that can be set to FALSE in order to always uncheck the "remember authz" check box. David -------------- next part -------------- A non-text attachment was scrubbed... Name: polkit-gnome-retain-authorizations-gconf.patch Type: text/x-patch Size: 8617 bytes Desc: not available Url : http://lists.freedesktop.org/archives/polkit-devel/attachments/20080718/fd2cafd9/attachment.bin From dirTdogE at Gmail.com Fri Jul 18 07:15:53 2008 From: dirTdogE at Gmail.com (dawg) Date: Fri, 18 Jul 2008 10:15:53 -0400 Subject: Question - PolicyKit In-Reply-To: <1216390051.11594.2.camel@x61.fubar.dk> References: <487A8D6E.6050400@Gmail.com> <1216147128.8536.12.camel@x61.fubar.dk> <487CF41F.8070208@Gmail.com> <1216149964.8536.29.camel@x61.fubar.dk> <487D0699.4080905@Gmail.com> <1216229860.3329.29.camel@x61.fubar.dk> <487E333B.1030206@redhat.com> <1216390051.11594.2.camel@x61.fubar.dk> Message-ID: <4880A599.2010803@Gmail.com> David Zeuthen wrote: > On Wed, 2008-07-16 at 20:06 +0200, Michael Biebl wrote: > >> 2008/7/16 Stephen Gallagher : >> >>> David, what about simply storing the fact that, the last time through, >>> the user opted to uncheck that box. If they have done so once, retain >>> that state for future authorization requests until they manually check >>> it again. This would avoid the situation dawg described where a user has >>> to actively choose to remove the checkbox each and every time. >>> >> TBH, I thought this is exactly the feature dawg was requesting (and I >> admit that I think it would be useful). >> > > OK, I've committed the attached patch that does this. It also includes a > boolean that can be set to FALSE in order to always uncheck the > "remember authz" check box. > Thank you Mr. Zeuthen. I appreciate your time and effort :-) > David > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freedesktop.org/archives/polkit-devel/attachments/20080718/1c788c0b/attachment.html From david at fubar.dk Fri Jul 18 08:00:18 2008 From: david at fubar.dk (David Zeuthen) Date: Fri, 18 Jul 2008 11:00:18 -0400 Subject: Deadline for Plumbers Conference CFP Message-ID: <1216393218.11594.15.camel@x61.fubar.dk> Hi, (and sorry for cross-posting) This is just a reminder that speaker proposals for Plumbers Conference must be submitted no later than Sunday 20 July 2008 20:00 (8 PM) UTC. There are going to be the following microconfs * The future of Linux storage * Video input infrastructure and V4L2 * Power management and tools for efficient resource usage * Future displays and input devices * D-Bus for desktop integration * Linux server management * XCB and graphics * Audio * Kernel/userspace interfaces * Debugging, tuning, tracing, and profiling More information about the conference including how to submit proposals can be found here http://linuxplumbersconf.org/cfp/ Hoping to see many of you in Portland! Thanks, David From gnomeuser8 at googlemail.com Sun Jul 20 06:24:13 2008 From: gnomeuser8 at googlemail.com (- -) Date: Sun, 20 Jul 2008 15:24:13 +0200 Subject: Give Authorizations via yes/no dialog In-Reply-To: <81c004d60807190315p10c69208y721ae8deb81cf1b@mail.gmail.com> References: <81c004d60807190315p10c69208y721ae8deb81cf1b@mail.gmail.com> Message-ID: <81c004d60807200624l4e0e50e3pf45990af1a4be90c@mail.gmail.com> From: gnomeuser8 at googlemail.com Date: 2008/7/19 Subject: Give Authorizations via yes/no dialog To: polkit-devel at lists.freedesktop.org Currently I can choose pam authentication (with my password) or pam authentication as admin (with admin password). I would like to authenticate with simply clicking on yes or no to give the application the authorization. You already grab the pointer, I think, so only I can do this and not any malware. This also does increase security: Malware could simulate a policykit authorization dialog for an easy thing (access to USB-Stick), you enter your password and then it can use sudo to get root rights. When it simulate an yes/no dialog the malware can't do anything with your answer. ;) The authorization should be kept indefinitely for the local active session and the same application. You already said you trust this application, why you shouldn't say the same next day? From patrys at pld-linux.org Sun Jul 20 06:40:23 2008 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Sun, 20 Jul 2008 15:40:23 +0200 Subject: Give Authorizations via yes/no dialog In-Reply-To: <81c004d60807200624l4e0e50e3pf45990af1a4be90c@mail.gmail.com> References: <81c004d60807190315p10c69208y721ae8deb81cf1b@mail.gmail.com> <81c004d60807200624l4e0e50e3pf45990af1a4be90c@mail.gmail.com> Message-ID: <89b6ba3a0807200640y58f387c1ief4eec4ef0c5c69a@mail.gmail.com> On Sun, Jul 20, 2008 at 3:24 PM, - - wrote: > From: gnomeuser8 at googlemail.com > Date: 2008/7/19 > Subject: Give Authorizations via yes/no dialog > To: polkit-devel at lists.freedesktop.org > > > Currently I can choose pam authentication (with my password) or pam > authentication as admin (with admin password). I would like to > authenticate with simply clicking on yes or no to give the application > the authorization. > > You already grab the pointer, I think, so only I can do this and not > any malware. This also does increase security: Malware could simulate > a policykit authorization dialog for an easy thing (access to > USB-Stick), you enter your password and then it can use sudo to get > root rights. When it simulate an yes/no dialog the malware can't do > anything with your answer. ;) > > The authorization should be kept indefinitely for the local active > session and the same application. You already said you trust this > application, why you shouldn't say the same next day? Forgive me if I'm high on some weird FOSS weed but isn't polkit about authorizing users as opposed to applications? All applications installed are trusted equally. The dialogs are only there for desktop systems where there is no admin to grant you the necessary rights (otherwise we'd see all users run X as root which brings us back to the old Windows era). Also you might like to double check your first and last name as to me they look like dashes. -- Patryk Zawadzki PLD Linux Distribution From david at fubar.dk Tue Jul 22 11:51:43 2008 From: david at fubar.dk (David Zeuthen) Date: Tue, 22 Jul 2008 14:51:43 -0400 Subject: 0.9 release Message-ID: <1216752703.31562.6.camel@x61.fubar.dk> Hey, Time for some new releases http://hal.freedesktop.org/releases/PolicyKit-0.9.tar.gz http://hal.freedesktop.org/releases/PolicyKit-gnome-0.9.tar.bz2 Release notes below. Not very exciting but some new translations. FWIW, I expect to start working on something like this http://www.freedesktop.org/wiki/Software/PolicyKit/PluggableArchitecture in the near future. This is needed for the FreeIPA-ish integration (e.g. create a plug-in architecture suitable FreeIPA and projects similar to it) and will also help us get rid of most of the the setuid/setgid helpers in the local machine use case. Comments, of course, more than welcome. As a reuslt, 0.10 might be a bit out. In the mean time we can do 0.9.x releases if needed. David ========== PolicyKit 0.9 ========== Released on July 22 2008. This release should be ABI compatible with PolicyKit 0.6 and later. David Zeuthen (10): need to link with libkit.la for some helpers fix some build stuff to so the test suites run fix autotools screwup fix typo always allow uid 0 to ask about authorizations for anyone fix up permissions / docs for certain helpers and files/directories update README (for the right wiki page) and COPYING (for my email address) update NEWS for release fix 'make distcheck' update NEWS again Joe Marcus Clarke (2): add support for FreeBSD remove watch on fd when reaching EOF ========== PolicyKit-gnome 0.9 ========== Release on July 22th 2008. Highlights of this release o Bug fixes o Avoid grabbing the pointer when showing dialog o Remember state for "remember authorization" check box per action. o New translations: ca, po, pt, ru, sk, cs, pt_BR, zh_CN, de Requirements for PolicyKit-gnome 0.9 - PolicyKit == 0.9 - GTK+ >= 2.12 - dbus >= 1.0 - dbus-glib >= 0.71 - gnome-vfs >= 2.4 - libsexy >= 0.1.11 - GConf >= 2.8 From david at fubar.dk Tue Jul 22 11:59:37 2008 From: david at fubar.dk (David Zeuthen) Date: Tue, 22 Jul 2008 14:59:37 -0400 Subject: 0.9 release In-Reply-To: <1216752703.31562.6.camel@x61.fubar.dk> References: <1216752703.31562.6.camel@x61.fubar.dk> Message-ID: <1216753177.8296.1.camel@x61.fubar.dk> On Tue, 2008-07-22 at 14:51 -0400, David Zeuthen wrote: > As a reuslt, 0.10 might be a bit out. In the mean time we can do 0.9.x > releases if needed. Btw, the Python bindings are not in 0.9. Sorry about that. We should do a 0.9.1 release with them. David From sgallagh at redhat.com Tue Jul 22 12:17:35 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 22 Jul 2008 15:17:35 -0400 Subject: 0.9 release In-Reply-To: <1216753177.8296.1.camel@x61.fubar.dk> References: <1216752703.31562.6.camel@x61.fubar.dk> <1216753177.8296.1.camel@x61.fubar.dk> Message-ID: <4886324F.20805@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Zeuthen wrote: > On Tue, 2008-07-22 at 14:51 -0400, David Zeuthen wrote: >> As a reuslt, 0.10 might be a bit out. In the mean time we can do 0.9.x >> releases if needed. > > Btw, the Python bindings are not in 0.9. Sorry about that. We should do > a 0.9.1 release with them. I agree, those will come in very handy, especially in relation to the 1.0 (0.10.0?) plan. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiGMk8ACgkQc7MaxVic+2qakwCgyKJbkOizhDyksN2T8Bfbq7ug yqkAnjJXWkFI9SjWPwrMpSdmPVz0ym8O =nZNz -----END PGP SIGNATURE----- From gnomeuser8 at googlemail.com Fri Jul 25 10:58:03 2008 From: gnomeuser8 at googlemail.com (Mark Hendricks) Date: Fri, 25 Jul 2008 19:58:03 +0200 Subject: Application authorization system Message-ID: <81c004d60807251058x2874c7e1k92e71a2d0d3f958e@mail.gmail.com> PolicyKit is a system you use to set authorizations for users. The system can give these authorizations under certain circumstances. I need to call my administrator to change my authorizations. I'm looking for a possibility to limit my own authorizations myself. Only applications I trust should be able to use certain of them. May it's possible to write a policykit backend for this. So any system service which does use policykit interface, can use the application authorization system So differ between user rights and application rights. Note that the user right could limited to certain applications (already possible), so you only can allow applications yourself you have the authorization for. Admin does give user authorizations, user does give applications authorizations.