LXDE - Lightweight X Desktop Environment

* PCMan <pcman.tw@...> [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

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 <pcman.tw@...> 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.
>

* PCMan <pcman.tw@...> [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

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
<guido+sourceforge.net@...> wrote:
> * PCMan <pcman.tw@...> [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
>

* PCMan <pcman.tw@...> [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

On Tue, Sep 14, 2010 at 6:25 PM, Guido Berhoerster
<guido+sourceforge.net@...> wrote:
> * PCMan <pcman.tw@...> [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
>

* PCMan <pcman.tw@...> [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

On Wed, Sep 15, 2010 at 4:19 AM, Guido Berhoerster
<guido+sourceforge.net@...> wrote:
> * PCMan <pcman.tw@...> [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
>

* PCMan <pcman.tw@...> [2010-09-14 22:46]:
> On Wed, Sep 15, 2010 at 4:19 AM, Guido Berhoerster
> <guido+sourceforge.net@...> wrote:
> > * PCMan <pcman.tw@...> [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

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
<guido+sourceforge.net@...> wrote:
> * PCMan <pcman.tw@...> [2010-09-14 22:46]:
>> On Wed, Sep 15, 2010 at 4:19 AM, Guido Berhoerster
>> <guido+sourceforge.net@...> wrote:
>> > * PCMan <pcman.tw@...> [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
>

* PCMan <pcman.tw@...> [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

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

* Guido Berhoerster <guido+sourceforge.net@...> [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

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
Usupov.Radik@...
Tel: 7 (843) 533-88-14
Jabber: radyus@...
Skype: Radik.Usupov
Russian Federation, Kazan, Zinina str. 3a.
http://www.cg.ru