Bug 143859 - lock & hibernate allowing unauthorised access
Summary: lock & hibernate allowing unauthorised access
Status: RESOLVED FIXED
Alias: None
Product: klaptopdaemon
Classification: Miscellaneous
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Paul Campbell
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-05 01:27 UTC by Raúl
Modified: 2007-10-05 00:53 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Better patch (2rd try) (724 bytes, patch)
2007-06-18 17:13 UTC, Raúl
Details
Patch to solve the problem using the DCOPClient approach. (751 bytes, patch)
2007-06-25 00:43 UTC, Raúl
Details
Patch to solve the problem using the DCOPClient approach. (1.37 KB, patch)
2007-06-25 00:44 UTC, Raúl
Details
Patch to solve the problem using the DCOPRef approach. (801 bytes, patch)
2007-06-25 00:59 UTC, Raúl
Details
DCOPRef patch with changes suggested. (777 bytes, patch)
2007-06-26 01:41 UTC, Raúl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Raúl 2007-04-05 01:27:03 UTC
Version:            (using KDE KDE 3.5.6)
Installed from:    Debian testing/unstable Packages

On heavy load, when clicking on Lock & hibernate gets effectively the system into hibernation. The problem is that when resuming there could be a small amount of time (2-4sec) where the session is not locked.

This is tested when not using uswsusp or hibernate scripts, when klaptop_acpi_helper forces the hibernation writing into /proc or /sys power interfaces.

The problem is that the dcop call used for locking the system (send) is asynchronous (daemondock.cpp:500) so the hibernation starts without waiting for the locks is already done.

This is filed after debian bug #416824 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416824
Comment 1 Raúl 2007-04-05 01:28:00 UTC
I propose a possible patch(currently untested) for this:

--- daemondock.cpp      (revisión: 650614)
+++ daemondock.cpp      (copia de trabajo)
@@ -500,8 +500,11 @@
 void laptop_dock::invokeLockHibernation()
 {
   DCOPClient* client = kapp->dcopClient();
+  QCString dummyCS;
+  QByteArray dummyBA;
   if (client)
-      client->send("kdesktop", "KScreensaverIface", "lock()", "");
+//      client->send("kdesktop", "KScreensaverIface", "lock()", "");
+      client->call("kdesktop", "KScreensaverIface", "lock()", "", dummyCS, dummyBA, true);
   laptop_portable::invoke_hibernation();
 }
 void laptop_dock::invokeStandby()
Comment 2 Raúl 2007-04-05 02:39:56 UTC
Well forget about the previous patch, after some more talk at #kde I got this better one (it even compiles :P ):

-8<----
Index: daemondock.cpp
===================================================================
--- daemondock.cpp      (revisión: 650614)
+++ daemondock.cpp      (copia de trabajo)
@@ -30,6 +30,7 @@
 #include <klocale.h>
 #include <kpopupmenu.h>
 #include <dcopclient.h>
+#include <dcopref.h>
 #include "kpcmciainfo.h"
 #include "daemondock.h"
 #include "portable.h"
@@ -501,7 +502,7 @@
 {
   DCOPClient* client = kapp->dcopClient();
   if (client)
-      client->send("kdesktop", "KScreensaverIface", "lock()", "");
+      DCOPRef("kdesktop", "KScreenSaverIface").call("lock");
   laptop_portable::invoke_hibernation();
 }
 void laptop_dock::invokeStandby()
-->8------
Comment 3 Marcus D. Hanwell 2007-05-25 15:49:48 UTC
The patch in comment 2 is currently being used in the Gentoo patchset. I would appreciate hearing back from the maintainer of the package on whether this is the best solution. I am told Debian are also using this patch. Thanks.
Comment 4 Ana Guerrero 2007-06-17 11:59:22 UTC
If you read in the Debian bug report at:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416824
you can see this patch might not work.
Comment 5 Raúl 2007-06-18 17:07:45 UTC
OK, I'm the one to blame here. After some more researching I saw this patch was not working, even I think it did on 3.5.5. Anyway the problem is that it seems that you need to call attach() for the DCOPClient in order it to be useful at all. This is weird since I suppose that even the kde base code should call attach() and it does not.

Here's a patch including this observations. Sorry for the nuissances.

-8<---- 
Index: daemondock.cpp
===================================================================
--- daemondock.cpp      (revisión: 677152)
+++ daemondock.cpp      (copia de trabajo)
@@ -30,6 +30,7 @@
 #include <klocale.h>
 #include <kpopupmenu.h>
 #include <dcopclient.h>
+#include <dcopref.h>
 #include "kpcmciainfo.h"
 #include "daemondock.h"
 #include "portable.h"
@@ -501,7 +502,10 @@
 {
   DCOPClient* client = kapp->dcopClient();
   if (client)
-      client->send("kdesktop", "KScreensaverIface", "lock()", "");
+  {
+    client->attach();
+    DCOPRef("kdesktop", "KScreenSaverIface").call("lock");
+  }
   laptop_portable::invoke_hibernation();
 }
 void laptop_dock::invokeStandby()
-->8------ 
Comment 6 Raúl 2007-06-18 17:13:27 UTC
Created attachment 20887 [details]
Better patch (2rd try)

I thought about this better option. Choose yourself.
(Self reminder: think before write).
Comment 7 Raúl 2007-06-25 00:41:29 UTC
After some mail-listing and tests I went to find that none of the previous patches did the work properly. I was centered in using the DCOPRef object approach but this doesn't seem to work is a DCOPClient object is involved near.

So the two options I thought are using DCOPClient as it is now, but adding the necessary changes to allow a DCOP call(synchronous) instead of a send call (asynchronous). First patch to follow.

The other option is keep trying with the DCOPRef object and this involves adding the DCOPClient usage as I mentioned. Second patch to follow.

I've tried both patches (now for real) and I saw it worked for me, but feedback is appreciated.

As to what it more adequate to KDE I'm not sure, the DCOPRef approach seems cleaner and easier to me, but the DCOPClient one seems a little less(not much less, BTW) cleaner. So this is any KDE wise who has to take the decision in case this is deemed to be important.

I also have to note that patches are just for the hibernate functionality, not for the suspend (to ram) functionality since the bug just covers the former functionality.

Comment 8 Raúl 2007-06-25 00:43:45 UTC
Created attachment 20947 [details]
Patch to solve the problem using the DCOPClient approach.

This patch uses the DCOPClient call() function(synchronous) to wait the desktop
to be locked before invoking hibernate.
Comment 9 Raúl 2007-06-25 00:44:49 UTC
Created attachment 20948 [details]
Patch to solve the problem using the DCOPClient approach.

This patch uses the DCOPRef approach to make a synchronous call() that locks
before invoking the hibernate functionality.
Comment 10 Raúl 2007-06-25 00:59:47 UTC
Created attachment 20949 [details]
Patch to solve the problem using the DCOPRef approach.

This patch uses the DCOPRef approach to make a synchronous call() that locks
before invoking the hibernate functionality.
Comment 11 David Faure 2007-06-25 17:36:12 UTC
DCOPRef approached preferred :)
You can probably remove the unused reply variable.
Comment 12 Raúl 2007-06-26 00:47:52 UTC
Thank you very much for the feedback, believe me when I say it's more than appreciated. I have no problem in doing as you say, but if you don't mind I will test it with those changes. The reason of including that variable is that this function has been a little tricky and I wanted to make sure that it was working. It worked like that but I was afraid it stopped working with slight modifications.

I'll go for that right now...

Regards,
Comment 13 Raúl 2007-06-26 01:41:39 UTC
Created attachment 20960 [details]
DCOPRef patch with changes suggested.

Here is the asked "one-liner" ;) Tested slilghtly, seems to work. Yet feedback
is appreciated. HTH.
Comment 14 Stephan Wezel 2007-10-02 23:03:49 UTC
for me the DCOPRef approach doesn't work. The kde session is not locked after resume from hibernating.
It works when using the "old" approach:
client->send("kdesktop", "KScreensaverIface", "lock()", ""); 

I'm using suspend2/tuxonice with the hibernate scripts v1.96 under gentoo
Comment 15 Raúl 2007-10-04 02:10:20 UTC
Stephan:
Could you tell us which exact version of kde are you trying with? and also if the command dcop kdesktop KScreensaverIface lock actually locks your desktop?

Thanks.
Comment 16 Stephan Wezel 2007-10-04 16:24:28 UTC
I'm using kde 3.5.7
the command "dcop kdesktop KScreensaverIface lock" locks my desktop.
If i activate the LockKDE command in the hibernate-script the desktop is also locked when resume is finished.
Also the old method via 'client->send("kdesktop", "KScreensaverIface", "lock()", ""); ' in klaptopdaemon works.
Only the DCOPRef method doesn't work.
Comment 17 David Faure 2007-10-04 18:46:31 UTC
OK if you don't get DCOPRef to work, let's forget about that. Doesn't matter much for such a simple call. Which patch works for sure, so that we can apply it to KDE? (there are multiple variants of the dcopclient send patch in this report). 
Comment 18 Stephan Wezel 2007-10-04 19:21:13 UTC
Strange now it works also with the DCOPRef method.
hmm maybe i have overseen a type-failure in one of the parameters when i copied the DCOPRef method to the sources. But i will recheck it with the last patch from Raúl.
Comment 19 Stephan Wezel 2007-10-04 19:45:32 UTC
OK i must have done a mistake when i copied the DCOPRef line. Because now it works also with the DCOPRef method.
So this one-liner patch works for me now, too https://bugs.kde.org/attachment.cgi?id=20949&action=view
Comment 20 David Faure 2007-10-05 00:53:15 UTC
SVN commit 721296 by dfaure:

Apply patch from 143859, fixing lock & hibernate.
"The problem is that the dcop call used for locking the system (send) is asynchronous so the hibernation starts without waiting for the locking being already done"
BUG: 143859


 M  +4 -3      daemondock.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=721296