From: PCMan <pcm...@gm...> - 2010-09-12 08:53:58
|
Hello list, After lengthy discussions, to solve the issue that lxsession lacks locking mechanism making "suspend" and "hibernate" insecure, I'll like to make a conclusion here. Here is the proposal and I'm going to do this in a separate branch for testing. 1. Add two config keys to desktop.conf in [Session] group: * LockScreen=true/false (default to true to be more secure, but provide a GUI option somewhere to turn it off) * LockCommand= (default to empty string) 2. If LockScreen=false, don't do any locking at all. If LockCommand is set, use that command for screen locking. Otherwise, fallback to default locking mechanism 3. Perform following default locking mechanism proposed in issue #3030907 if a specific LockCommand is not set. http://sourceforge.net/tracker/?func=detail&aid=3030907&group_id=180858&atid=894871 Look for usable locking command in this list: "gnome-screensaver-command --lock", "xscreensaver-command -lock", "xlock -mode blank". (This list can be expanded later) 4. If possible, do #3 in a shell script rather than hard coding it in C source code for easier custimization. I believe that this should cover most needs. Is this proposal acceptable? If there is no objection and no one is working on this issue now, I want to do it this week. I'll do it in a separate branch without touching any existing code in master branch so nothing will be broken. If after testing it works, we prepare a new release for lxsession. This may not be the best solution, but at least I should try to fix it. Comments and suggestions are welcomed. |
From: Guido B. <gui...@be...> - 2010-09-13 08:39:18
Attachments:
lxsession-lock.sh
|
* PCMan <pcm...@gm...> [2010-09-12 10:53]: > Hello list, > After lengthy discussions, to solve the issue that lxsession lacks > locking mechanism making "suspend" and "hibernate" insecure, I'll like > to make a conclusion here. > Here is the proposal and I'm going to do this in a separate branch for testing. > > 1. Add two config keys to desktop.conf in [Session] group: > * LockScreen=true/false (default to true to be more secure, but > provide a GUI option somewhere to turn it off) > * LockCommand= (default to empty string) > 2. If LockScreen=false, don't do any locking at all. > If LockCommand is set, use that command for screen locking. > Otherwise, fallback to default locking mechanism What if LockCommand fails? > 3. Perform following default locking mechanism proposed in issue > #3030907 if a specific LockCommand is not set. > http://sourceforge.net/tracker/?func=detail&aid=3030907&group_id=180858&atid=894871 > Look for usable locking command in this list: > "gnome-screensaver-command --lock", "xscreensaver-command -lock", > "xlock -mode blank". (This list can be expanded later) > 4. If possible, do #3 in a shell script rather than hard coding it in > C source code for easier custimization. See attached shell script (assumes that the running screensave is in PATH), although I am not aware of any other locking commands which could be run from an LXDE session. -- Guido Berhoerster |
From: PCMan <pcm...@gm...> - 2010-09-13 17:38:17
|
The features mentitioned in this mail is implemanted in "lock" branch now. Please test if it works as expected. If there are no obvious problems and objections, I'd like to merge it to master branch to be included in the latest release of lxsession. http://lxde.git.sourceforge.net/git/gitweb.cgi?p=lxde/lxsession;a=shortlog;h=refs/heads/lock Thank you all. On Sun, Sep 12, 2010 at 4:53 PM, PCMan <pcm...@gm...> wrote: > Hello list, > After lengthy discussions, to solve the issue that lxsession lacks > locking mechanism making "suspend" and "hibernate" insecure, I'll like > to make a conclusion here. > Here is the proposal and I'm going to do this in a separate branch for testing. > > 1. Add two config keys to desktop.conf in [Session] group: > * LockScreen=true/false (default to true to be more secure, but > provide a GUI option somewhere to turn it off) > * LockCommand= (default to empty string) > 2. If LockScreen=false, don't do any locking at all. > If LockCommand is set, use that command for screen locking. > Otherwise, fallback to default locking mechanism > 3. Perform following default locking mechanism proposed in issue > #3030907 if a specific LockCommand is not set. > http://sourceforge.net/tracker/?func=detail&aid=3030907&group_id=180858&atid=894871 > Look for usable locking command in this list: > "gnome-screensaver-command --lock", "xscreensaver-command -lock", > "xlock -mode blank". (This list can be expanded later) > 4. If possible, do #3 in a shell script rather than hard coding it in > C source code for easier custimization. > > I believe that this should cover most needs. Is this proposal acceptable? > If there is no objection and no one is working on this issue now, I > want to do it this week. > I'll do it in a separate branch without touching any existing code in > master branch so nothing will be broken. > If after testing it works, we prepare a new release for lxsession. > This may not be the best solution, but at least I should try to fix it. > > Comments and suggestions are welcomed. > |
From: Радик Ю. <ra...@ya...> - 2011-10-12 14:28:44
|
13.09.2010 21:38, PCMan пишет: > The features mentitioned in this mail is implemanted in "lock" branch now. > Please test if it works as expected. > If there are no obvious problems and objections, I'd like to merge it > to master branch to be included in the latest release of lxsession. > > http://lxde.git.sourceforge.net/git/gitweb.cgi?p=lxde/lxsession;a=shortlog;h=refs/heads/lock > > Thank you all. Hello! I tried merge lock branch with the master. Got a problem with lxsession-logout.c Could you move those changes to a new version of lxsession? I'll test it. -- Best regards, Radik Usupov Information Systems' infrastructure Department Engineer Center Group Usu...@cg... Tel: 7 (843) 533-88-14 Jabber: ra...@ja... Skype: Radik.Usupov Russian Federation, Kazan, Zinina str. 3a. http://www.cg.ru |
From: Guido B. <gui...@be...> - 2010-09-13 18:59:22
|
* PCMan <pcm...@gm...> [2010-09-13 19:38]: > The features mentitioned in this mail is implemanted in "lock" branch now. > Please test if it works as expected. > If there are no obvious problems and objections, I'd like to merge it > to master branch to be included in the latest release of lxsession. > > http://lxde.git.sourceforge.net/git/gitweb.cgi?p=lxde/lxsession;a=shortlog;h=refs/heads/lock Please use the script I sent you, it does exactly the same as yours in 8 instead of 23 lines and it is actually portable. -- Guido Berhoerster |
From: PCMan <pcm...@gm...> - 2010-09-14 04:56:06
|
No, your script didn't do the right thing. If gnome-screensaver is not running, gnome-screen-saver-command shouldn't be called. If you do this, gnome-screen-saver will be launched, but nothing will happen. At the same time it's possible that the user is actually running xscreensaver. If the user is running xscreensaver, and you call gnome-screensaver-command, this will result in gnome-screensaver being launched and xscreensaver being bypassed, which is just the wrong behavior. Checking if the screensaver is currently running is necessary. Relying on failure of their *-command programs is not a reliable solution. That's why your script is not used directly. On Tue, Sep 14, 2010 at 3:04 AM, Guido Berhoerster <gui...@be...> wrote: > * PCMan <pcm...@gm...> [2010-09-13 19:38]: >> The features mentitioned in this mail is implemanted in "lock" branch now. >> Please test if it works as expected. >> If there are no obvious problems and objections, I'd like to merge it >> to master branch to be included in the latest release of lxsession. >> >> http://lxde.git.sourceforge.net/git/gitweb.cgi?p=lxde/lxsession;a=shortlog;h=refs/heads/lock > > Please use the script I sent you, it does exactly the same as > yours in 8 instead of 23 lines and it is actually portable. > > -- > Guido Berhoerster > |
From: Guido B. <gui...@be...> - 2010-09-14 10:20:05
|
* PCMan <pcm...@gm...> [2010-09-14 06:56]: > No, your script didn't do the right thing. > If gnome-screensaver is not running, gnome-screen-saver-command > shouldn't be called. > If you do this, gnome-screen-saver will be launched, but nothing will happen. > At the same time it's possible that the user is actually running xscreensaver. No, running "gnome-screensaver-command -l" without gnome-screensaver running will print **Message: Screensaver is not running! and return exit code 1. > If the user is running xscreensaver, and you call > gnome-screensaver-command, this will result in gnome-screensaver being > launched and xscreensaver being bypassed, which is just the wrong > behavior. > > Checking if the screensaver is currently running is necessary. > Relying on failure of their *-command programs is not a reliable solution. > That's why your script is not used directly. In fact it is the exact opposite, your approach is unportable and completely broken in different ways. Firstly, pgrep will happily match the screensaver of any user which might be logged into the system, it will even match if somebody is running "vi gnome-screensaver.txt", it is thus completely unsuitable for the job. Secondly, this check is unnecessary since the exit code of xscreensaver-command and gnome-screensaver-command will be 1 if the respective screensaver is not running. -- Guido Berhoerster |
From: PCMan <pcm...@gm...> - 2010-09-14 13:48:03
|
On Tue, Sep 14, 2010 at 6:25 PM, Guido Berhoerster <gui...@be...> wrote: > * PCMan <pcm...@gm...> [2010-09-14 06:56]: >> No, your script didn't do the right thing. >> If gnome-screensaver is not running, gnome-screen-saver-command >> shouldn't be called. >> If you do this, gnome-screen-saver will be launched, but nothing will happen. >> At the same time it's possible that the user is actually running xscreensaver. > > No, running "gnome-screensaver-command -l" without > gnome-screensaver running will print > **Message: Screensaver is not running! > and return exit code 1. This is not the case on my box. It tried to launch gnome-screensaver even if this command failed. I'm using ubuntu 10.04. Please read the source code of gnome-screesaver-command. Is doesn't do what you said. http://git.gnome.org/browse/gnome-screensaver/tree/src/gnome-screensaver-command.c It exit with code 1 only when you pass wrong arguments, when dbus is not available, and when you query the version number. It return 0 even if gnome-screensaver is not running. The dbus call, however, will cause the gnome-screensaver service being launched. I don't know the version of gnome-screensaver you're using, but from the latest code in git, it doesn't not work the way we want. >> If the user is running xscreensaver, and you call >> gnome-screensaver-command, this will result in gnome-screensaver being >> launched and xscreensaver being bypassed, which is just the wrong >> behavior. >> >> Checking if the screensaver is currently running is necessary. >> Relying on failure of their *-command programs is not a reliable solution. >> That's why your script is not used directly. > > In fact it is the exact opposite, your approach is unportable and > completely broken in different ways. > Firstly, pgrep will happily match the screensaver of any user > which might be logged into the system, it will even match if > somebody is running "vi gnome-screensaver.txt", it is thus > completely unsuitable for the job. Then we need a better way to check it. > Secondly, this check is unnecessary since the exit code of > xscreensaver-command and gnome-screensaver-command will be 1 if > the respective screensaver is not running. > > -- > Guido Berhoerster > |
From: Guido B. <gui...@be...> - 2010-09-14 20:14:01
|
* PCMan <pcm...@gm...> [2010-09-14 15:48]: > > No, running "gnome-screensaver-command -l" without > > gnome-screensaver running will print > > **Message: Screensaver is not running! > > and return exit code 1. > This is not the case on my box. > It tried to launch gnome-screensaver even if this command failed. > I'm using ubuntu 10.04. > > Please read the source code of gnome-screesaver-command. > Is doesn't do what you said. > > http://git.gnome.org/browse/gnome-screensaver/tree/src/gnome-screensaver-command.c > > It exit with code 1 only when you pass wrong arguments, when dbus is > not available, and when you query the version number. > It return 0 even if gnome-screensaver is not running. > The dbus call, however, will cause the gnome-screensaver service being launched. > I don't know the version of gnome-screensaver you're using, but from > the latest code in git, it doesn't not work the way we want. I admit you are right on this one, the DBus autostart seems to have been introduced in April: http://git.gnome.org/browse/gnome-screensaver/commit/?id=47155576403fea9339a1f702e3dc63455b763fb8 They more or less silently changed the behavior of gnome-screensaver-command breaking shell scripts (including one of mine for inhibiting the screensaver while running an application) relying on the previous behavior which was modeled after xscreensaver-command, just lovely. If someone has gnome-screensaver installed and is running another screensaver I don't see any way to tell from a shellscript which one to use now. Looking for a process is just plainly broken and unreliable by principle, e.g. someome might suspend before the session has started gnome-screensaver, see https://bugzilla.gnome.org/show_bug.cgi?id=616225 For lxsession I'd propose to use my script and remove gnome-screensaver-command from the list. If someone wants to use it, it can still be added as an explicit locking command in the config file. Since I find changing the cli silently in a minor version upgrade unacceptable I am also going to file a bug against gnome-screensaver. -- Guido Berhoerster |
From: PCMan <pcm...@gm...> - 2010-09-14 20:46:04
|
On Wed, Sep 15, 2010 at 4:19 AM, Guido Berhoerster <gui...@be...> wrote: > * PCMan <pcm...@gm...> [2010-09-14 15:48]: >> > No, running "gnome-screensaver-command -l" without >> > gnome-screensaver running will print >> > **Message: Screensaver is not running! >> > and return exit code 1. >> This is not the case on my box. >> It tried to launch gnome-screensaver even if this command failed. >> I'm using ubuntu 10.04. >> >> Please read the source code of gnome-screesaver-command. >> Is doesn't do what you said. >> >> http://git.gnome.org/browse/gnome-screensaver/tree/src/gnome-screensaver-command.c >> >> It exit with code 1 only when you pass wrong arguments, when dbus is >> not available, and when you query the version number. >> It return 0 even if gnome-screensaver is not running. >> The dbus call, however, will cause the gnome-screensaver service being launched. >> I don't know the version of gnome-screensaver you're using, but from >> the latest code in git, it doesn't not work the way we want. > > I admit you are right on this one, the DBus autostart seems to > have been introduced in April: > http://git.gnome.org/browse/gnome-screensaver/commit/?id=47155576403fea9339a1f702e3dc63455b763fb8 > > They more or less silently changed the behavior of > gnome-screensaver-command breaking shell scripts (including one > of mine for inhibiting the screensaver while running an > application) relying on the previous behavior which was modeled > after xscreensaver-command, just lovely. Since they do things with the dirty way, here is a dirty solution I came up with. dbus-send --session --type=method_call --print-reply --dest=org.freedesktop.DBus / org.freedesktop.DBus.NameHasOwner string:"org.gnome.ScreenSaver" Maybe this command line can do the trick. > If someone has gnome-screensaver installed and is running another > screensaver I don't see any way to tell from a shellscript which > one to use now. Looking for a process is just plainly broken and > unreliable by principle, e.g. someome might suspend before the > session has started gnome-screensaver, see > https://bugzilla.gnome.org/show_bug.cgi?id=616225 But this should be a rare case. Maybe we should ask gnome-screensaver developers how to solve this. > For lxsession I'd propose to use my script and remove > gnome-screensaver-command from the list. If someone wants to use > it, it can still be added as an explicit locking command in the > config file. > > Since I find changing the cli silently in a minor version upgrade > unacceptable I am also going to file a bug against > gnome-screensaver. > -- > Guido Berhoerster > |
From: Guido B. <gui...@be...> - 2010-09-14 21:21:18
|
* PCMan <pcm...@gm...> [2010-09-14 22:46]: > On Wed, Sep 15, 2010 at 4:19 AM, Guido Berhoerster > <gui...@be...> wrote: > > * PCMan <pcm...@gm...> [2010-09-14 15:48]: > >> > No, running "gnome-screensaver-command -l" without > >> > gnome-screensaver running will print > >> > **Message: Screensaver is not running! > >> > and return exit code 1. > >> This is not the case on my box. > >> It tried to launch gnome-screensaver even if this command failed. > >> I'm using ubuntu 10.04. > >> > >> Please read the source code of gnome-screesaver-command. > >> Is doesn't do what you said. > >> > >> http://git.gnome.org/browse/gnome-screensaver/tree/src/gnome-screensaver-command.c > >> > >> It exit with code 1 only when you pass wrong arguments, when dbus is > >> not available, and when you query the version number. > >> It return 0 even if gnome-screensaver is not running. > >> The dbus call, however, will cause the gnome-screensaver service being launched. > >> I don't know the version of gnome-screensaver you're using, but from > >> the latest code in git, it doesn't not work the way we want. > > > > I admit you are right on this one, the DBus autostart seems to > > have been introduced in April: > > http://git.gnome.org/browse/gnome-screensaver/commit/?id=47155576403fea9339a1f702e3dc63455b763fb8 > > > > They more or less silently changed the behavior of > > gnome-screensaver-command breaking shell scripts (including one > > of mine for inhibiting the screensaver while running an > > application) relying on the previous behavior which was modeled > > after xscreensaver-command, just lovely. > > Since they do things with the dirty way, here is a dirty solution I > came up with. > > dbus-send --session --type=method_call --print-reply > --dest=org.freedesktop.DBus / org.freedesktop.DBus.NameHasOwner > string:"org.gnome.ScreenSaver" > > Maybe this command line can do the trick. The problem is that dbus-send might not necessarily be installed even when dbus itself is. > > If someone has gnome-screensaver installed and is running another > > screensaver I don't see any way to tell from a shellscript which > > one to use now. Looking for a process is just plainly broken and > > unreliable by principle, e.g. someome might suspend before the > > session has started gnome-screensaver, see > > https://bugzilla.gnome.org/show_bug.cgi?id=616225 > But this should be a rare case. Maybe we should ask gnome-screensaver > developers how to solve this. I think that is the proper solution. -- Guido Berhoerster |
From: Guido B. <gui...@be...> - 2010-10-19 21:03:58
|
* Guido Berhoerster <gui...@be...> [2010-09-14 23:22]: > > > If someone has gnome-screensaver installed and is running another > > > screensaver I don't see any way to tell from a shellscript which > > > one to use now. Looking for a process is just plainly broken and > > > unreliable by principle, e.g. someome might suspend before the > > > session has started gnome-screensaver, see > > > https://bugzilla.gnome.org/show_bug.cgi?id=616225 > > But this should be a rare case. Maybe we should ask gnome-screensaver > > developers how to solve this. > > I think that is the proper solution. gnome-screensaver has been fixed and gnome-screensaver-command now works like before the DBus autostart was introduced, see https://bugzilla.gnome.org/show_bug.cgi?id=629740 http://git.gnome.org/browse/gnome-screensaver/commit/?id=a37f531e5ba968bea445e82dbc418d8b7ced219c -- Guido Berhoerster |
From: PCMan <pcm...@gm...> - 2010-09-15 01:37:05
|
So here is the design choice. To implement locking program detection in script and depends on dbus-send, or to implement this in C code to have no other dependencies since we already use dbus? Maybe this time doing it in C can make things easier than using scripts. Suggestions? On Wed, Sep 15, 2010 at 5:26 AM, Guido Berhoerster <gui...@be...> wrote: > * PCMan <pcm...@gm...> [2010-09-14 22:46]: >> On Wed, Sep 15, 2010 at 4:19 AM, Guido Berhoerster >> <gui...@be...> wrote: >> > * PCMan <pcm...@gm...> [2010-09-14 15:48]: >> >> > No, running "gnome-screensaver-command -l" without >> >> > gnome-screensaver running will print >> >> > **Message: Screensaver is not running! >> >> > and return exit code 1. >> >> This is not the case on my box. >> >> It tried to launch gnome-screensaver even if this command failed. >> >> I'm using ubuntu 10.04. >> >> >> >> Please read the source code of gnome-screesaver-command. >> >> Is doesn't do what you said. >> >> >> >> http://git.gnome.org/browse/gnome-screensaver/tree/src/gnome-screensaver-command.c >> >> >> >> It exit with code 1 only when you pass wrong arguments, when dbus is >> >> not available, and when you query the version number. >> >> It return 0 even if gnome-screensaver is not running. >> >> The dbus call, however, will cause the gnome-screensaver service being launched. >> >> I don't know the version of gnome-screensaver you're using, but from >> >> the latest code in git, it doesn't not work the way we want. >> > >> > I admit you are right on this one, the DBus autostart seems to >> > have been introduced in April: >> > http://git.gnome.org/browse/gnome-screensaver/commit/?id=47155576403fea9339a1f702e3dc63455b763fb8 >> > >> > They more or less silently changed the behavior of >> > gnome-screensaver-command breaking shell scripts (including one >> > of mine for inhibiting the screensaver while running an >> > application) relying on the previous behavior which was modeled >> > after xscreensaver-command, just lovely. >> >> Since they do things with the dirty way, here is a dirty solution I >> came up with. >> >> dbus-send --session --type=method_call --print-reply >> --dest=org.freedesktop.DBus / org.freedesktop.DBus.NameHasOwner >> string:"org.gnome.ScreenSaver" >> >> Maybe this command line can do the trick. > > The problem is that dbus-send might not necessarily be installed > even when dbus itself is. > >> > If someone has gnome-screensaver installed and is running another >> > screensaver I don't see any way to tell from a shellscript which >> > one to use now. Looking for a process is just plainly broken and >> > unreliable by principle, e.g. someome might suspend before the >> > session has started gnome-screensaver, see >> > https://bugzilla.gnome.org/show_bug.cgi?id=616225 >> But this should be a rare case. Maybe we should ask gnome-screensaver >> developers how to solve this. > > I think that is the proper solution. > > -- > Guido Berhoerster > |
From: Guido B. <gui...@be...> - 2010-09-15 07:37:04
|
* PCMan <pcm...@gm...> [2010-09-15 03:37]: > So here is the design choice. > To implement locking program detection in script and depends on > dbus-send, or to implement this in C code to have no other > dependencies since we already use dbus? > Maybe this time doing it in C can make things easier than using scripts. > Suggestions? That's what I suggested from the beginning, particularly given that there seems to be only gnome-screensaver, xscreensaver, and xlockmore (anything else?) and there is already the possibility to explicitly specify a command in the lxsession config file. -- Guido Berhoerster |
From: Chris W. <chr...@ap...> - 2010-09-26 08:52:07
|
I don't know whether this is of any interest at all, but just in case: CrunchBang Linux has a script called cb-lock for running xscreensaver. These are the contents (from my installation, CrunchBang Statler (Alpha 2): #!/bin/bash # cb-lock # ------- # This is a wrapper for the 'xscreensaver-command -lock' command. # If running in live mode, offer up a prompt detailing the live session password. # Else, run xscreensaver-command -lock. # Simples! if [ -d /live/cow ]; then if [ ! -f /home/$USER/.config/crunchbang/cb-lock ]; then zenity --info --title="Lock screen info:" --text="Lock screen has detected you are running a live session.\nThe password needed to unlock the screen is \"live\".\nThis notice will only be displayed once per live session." if [ ! -d /home/$USER/.config/crunchbang ]; then mkdir /home/$USER/.config/crunchbang fi touch /home/$USER/.config/crunchbang/cb-lock xscreensaver-command -lock exit 0 fi xscreensaver-command -lock else xscreensaver-command -lock fi exit 0 -- Chris Watkins Appropedia.org - Sharing knowledge to build rich, sustainable lives. blogs.appropedia.org community.livejournal.com/appropedia identi.ca/appropedia twitter.com/appropedia |