Why I can't compile upower without policykit and other *kit stuff?
Why I can't compile upower without policykit and other *kit stuff? ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: Why I can't compile upower without policykit and other *kit stuff?
On 7 May 2010 09:02, Baybal Ni wrote: > Why I can't compile upower without policykit and other *kit stuff? Because UPower uses PolicyKit as a security framework. Why do you want to change it? Richard. ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: Why I can't compile upower without policykit and other *kit stuff?
Yes, if it's security matter at least make it working without suid root first, like use pam instead. This policykit is hardly a security framework. On 7 May 2010 01:26, "Richard Hughes" wrote: On 7 May 2010 09:02, Baybal Ni wrote: > Why I can't compile upower without pol... Because UPower uses PolicyKit as a security framework. Why do you want to change it? Richard. ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: Why I can't compile upower without policykit and other *kit stuff?
On Fri, May 7, 2010 at 4:34 AM, Baybal Ni wrote: > Yes, if it's security matter at least make it working without suid root > first, like use pam instead. This policykit is hardly a security framework. Can you elaborate on the last statement please? David ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Sleeping signal is only emitted if AboutToSleep is called
Hi! I'm one of the developer over at team-xbmc and I recently noticed that UPower have added the Sleeping and Resuming signals, awesome! I noticed a problem with them when implementing them into xbmc however. The resuming signal works fine but the sleeping signal is only emitted if I call AboutToSleep. According to docs its supposed to be emitted on calls to hibernate and suspend aswell, which its not. In XBMC we could easily call AboutToSleep first but gnome doesn't seem to do this and then the event won't get emitted to us and we are kept in the dark about the sleep. Also as an application all what I want is signals that happen when 1) a sleep will occur unless something goes terribly wrong (but note here it should be beyond the point of no return regarding cancelation of sleep). 2) on resume (this one works perfectly) and optionally 3) when the system might sleep but I have the power to cancel it. In 1 I must assume that the system will sleep and I can do stuff like stop playback etc. and 1 second is enough to handle anything to prepare for that. 3 would be nice since then I can do certain stuff that won't interfere with the usage of the application, like auto-saving something in case the sleep would fail. This one could easily be optional for the application thats about to call since the actual suspend will still signal sleeping. I consider the current sleep signal being 1, thus it might be abit weird to have AboutToSleep signal Sleeping since there is no obligation for another application to call suspend / hibernate. Perhaps I assume wrong here? Thanks for an awesome job, the new UPower is otherwise extremely good! (UDisk and those are aswell very nice). Cheers, Tobias. ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: Sleeping signal is only emitted if AboutToSleep is called
On 7 May 2010 20:30, Tobias Arrskog wrote: > I noticed a problem with them when implementing them into xbmc however. The > resuming signal works fine but the sleeping signal is only emitted if I call > AboutToSleep. That sounds like a bug. I'll fix that up now. Richard. ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: Sleeping signal is only emitted if AboutToSleep is called
On 7 May 2010 20:48, Richard Hughes wrote: > On 7 May 2010 20:30, Tobias Arrskog wrote: >> I noticed a problem with them when implementing them into xbmc however. The >> resuming signal works fine but the sleeping signal is only emitted if I call >> AboutToSleep. > > That sounds like a bug. I'll fix that up now. Could you try with upower from git master please? There's a SRPM here if that helps: http://people.freedesktop.org/~hughsient/fedora/13/SRPMS/ Thanks. Richard. ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Fwd: Why I can't compile upower without policykit and other *kit stuff?
On 7 May 2010 05:36, David Zeuthen wrote: > On Fri, May 7, 2010 at 4:34 AM, Baybal Ni wrote: >> Yes, if it's security matter at least make it working without suid root >> first, like use pam instead. This policykit is hardly a security framework. > > Can you elaborate on the last statement please? > > David > Just for its extensive use of such a suboptimal thing as suid it can be banished from some distros which accents on security. Secondly, a hack to pk client means that pk will issue whatever permissions set by user of defaults without further checks. And, thirdly a simplest hack will be launching a fake dbus, and exploiting it for whatever reason. PK utilises pam, and thus should be able to do things is a somehow more safe way, while it's not utilising even a glimpse of its features. ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: Why I can't compile upower without policykit and other *kit stuff?
On 7 May 2010 01:34, Baybal Ni wrote: > Yes, if it's security matter at least make it working without suid root > first, like use pam instead. This policykit is hardly a security framework. > > On 7 May 2010 01:26, "Richard Hughes" wrote: > > On 7 May 2010 09:02, Baybal Ni wrote: >> Why I can't compile upower without pol... > > Because UPower uses PolicyKit as a security framework. Why do you want > to change it? > > Richard. > Just for its extensive use of such a suboptimal thing as suid it can be banished from some distros which accents on security. Secondly, a hack to pk client means that pk will issue whatever permissions set by user of defaults without further checks. And, thirdly a simplest hack will be launching a fake dbus, and exploiting it for whatever reason. PK utilises pam, and thus should be able to do things is a somehow more safe way, while it's not utilising even a glimpse of its features. ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
