Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1072092 > unrolled thread

Bug#994762: warnings about session IDs

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#994762: warnings about session IDs Antoine Beaupre <anarcat@debian.org> - 2021-09-20 17:50 +0200
    Bug#994762: warnings about session IDs Ian Campbell <ijc@debian.org> - 2021-09-25 12:00 +0200
      Bug#994762: warnings about session IDs Antoine Beaupré <anarcat@debian.org> - 2021-09-27 15:40 +0200
        Bug#994762: warnings about session IDs Ian Campbell <ijc@debian.org> - 2021-10-17 08:40 +0200
          Bug#994762: warnings about session IDs Antoine Beaupré <anarcat@debian.org> - 2021-10-18 01:10 +0200
            Bug#994762: warnings about session IDs Ian Campbell <ijc@debian.org> - 2021-10-20 21:30 +0200
              Bug#994762: warnings about session IDs Antoine Beaupré <anarcat@debian.org> - 2021-10-21 02:20 +0200

#1072092 — Bug#994762: warnings about session IDs

Package: xss-lock
Version: 0.3.0-10+b1
Severity: normal

I'm not sure how to use this program. I have tried to start it from
systemd using the `.service` file provided by the package, but this
fails with:

    sep 20 11:38:29 curie xss-lock[3803849]: Error getting session: GDBus.Error:org.freedesktop.login1.NoSessionForPID: Caller does not belong to any known session.

When inspecting the service, the GRAPHICAL_SESSION_ID variable is not
actually set.

I have tried to run it from a xterm using:

    /usr/bin/xss-lock -l -n /usr/lib/xsecurelock/dimmer -- xsecurelock

and this fails with:

    ** (xss-lock:3806201): WARNING **: 11:41:13.273: Error getting session: GDBus.Error:org.freedesktop.login1.NoSessionForPID: PID 3806201 does not belong to any known session

Somehow it still seems to work, however, so I'm not sure what to do
with those warnings...
-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xss-lock depends on:
ii  libc6                2.31-13
ii  libglib2.0-0         2.66.8-1
ii  libxcb-screensaver0  1.14-3
ii  libxcb-util1         0.4.0-1+b1
ii  libxcb1              1.14-3

xss-lock recommends no packages.

xss-lock suggests no packages.

-- debconf-show failed

[toc] | [next] | [standalone]

#1072860

control: tag -1 upstream,help

Thanks for your report!

On Mon, 2021-09-20 at 11:42 -0400, Antoine Beaupre wrote:
> I'm not sure how to use this program.

FWIW I use it by launching from my .i3/config with:

    exec --no-startup-id exec xss-lock --transfer-sleep-lock -- i3lock -d --color 000000

Which desktop env are you using?

>  I have tried to start it from
> systemd using the `.service` file provided by the package, but this
> fails with:
> 
>     sep 20 11:38:29 curie xss-lock[3803849]: Error getting session:
> GDBus.Error:org.freedesktop.login1.NoSessionForPID: Caller does not
> belong to any known session.
> 
> When inspecting the service, the GRAPHICAL_SESSION_ID variable is not
> actually set.

In fact the only hit online is your bugreport AFAICT. I wonder if the
author of that service file used it as a placeholder to be replaced
with something specific to the actual environment or if it was
something they arranged locally some other way?

Have you tried just removing that bit of the service file? `-s` is
documented as `Use the session **ID** instead of the current session.`
so maybe it'll just DTRT?

> 
> I have tried to run it from a xterm using:
> 
>     /usr/bin/xss-lock -l -n /usr/lib/xsecurelock/dimmer --
> xsecurelock
> 
> and this fails with:
> 
>     ** (xss-lock:3806201): WARNING **: 11:41:13.273: Error getting
> session: GDBus.Error:org.freedesktop.login1.NoSessionForPID: PID
> 3806201 does not belong to any known session

Hrm, I don't see those, perhaps it is desktop or session manager
specific somehow. I'm using i3 under lightdm.

> Somehow it still seems to work, however, so I'm not sure what to do
> with those warnings...

Me neither and I'm afraid upstream[0] has been dormant for several
years so I'm rather reliant on contributions for issues people see
which I don't.

Perhaps
https://bitbucket.org/raymonad/xss-lock/issues/13/allow-operation-as-systemd-user-unit#comment-45869112
is useful, since they appear to be the author of the `-s` feature. And
https://bitbucket.org/raymonad/xss-lock/issues/13/allow-operation-as-systemd-user-unit#comment-46751262
then suggests using $XDG_SESSION_ID (but makes reference to having to
export it somehow...).

Worth a try I suppose, please let me know if it works and I'll update
the service file in the package.

Out-of-interest how does one go about activating the service file for
your user, I suppose you copy it to ~/.config somewhere or pass it to
some systemctl command -- it'd be great if I could add some
instructions to the docs.

Cheers,
Ian.

[0] https://bitbucket.org/raymonad/xss-lock/

[toc] | [prev] | [next] | [standalone]

#1073223

On 2021-09-25 10:14:46, Ian Campbell wrote:
> control: tag -1 upstream,help
>
> Thanks for your report!
>
> On Mon, 2021-09-20 at 11:42 -0400, Antoine Beaupre wrote:
>> I'm not sure how to use this program.
>
> FWIW I use it by launching from my .i3/config with:
>
>     exec --no-startup-id exec xss-lock --transfer-sleep-lock -- i3lock -d --color 000000
>
> Which desktop env are you using?

I'm using i3 as well, but I'm starting xss-lock from systemd, like
i3. I'm basically following:

https://vincent.bernat.ch/en/blog/2021-i3-window-manager#systemd-the-service-manager

... but now that I look at it more closely, he has a more elaborate
startup system than I expected for xss-lock, ie. this:

https://github.com/vincentbernat/i3wm-configuration/blob/master/dotfiles/systemd/xss-lock.service

actually calls that:

https://github.com/vincentbernat/i3wm-configuration/blob/master/bin/xss-lock

In the latter, they use XDG_SESSION_ID, I wonder if that might be the
trick I'm missing.

>>  I have tried to start it from
>> systemd using the `.service` file provided by the package, but this
>> fails with:
>> 
>>     sep 20 11:38:29 curie xss-lock[3803849]: Error getting session:
>> GDBus.Error:org.freedesktop.login1.NoSessionForPID: Caller does not
>> belong to any known session.
>> 
>> When inspecting the service, the GRAPHICAL_SESSION_ID variable is not
>> actually set.
>
> In fact the only hit online is your bugreport AFAICT. I wonder if the
> author of that service file used it as a placeholder to be replaced
> with something specific to the actual environment or if it was
> something they arranged locally some other way?
>
> Have you tried just removing that bit of the service file? `-s` is
> documented as `Use the session **ID** instead of the current session.`
> so maybe it'll just DTRT?

Yeah, that's what I'm doing, but then I get the error below:

>> I have tried to run it from a xterm using:
>> 
>>     /usr/bin/xss-lock -l -n /usr/lib/xsecurelock/dimmer --
>> xsecurelock
>> 
>> and this fails with:
>> 
>>     ** (xss-lock:3806201): WARNING **: 11:41:13.273: Error getting
>> session: GDBus.Error:org.freedesktop.login1.NoSessionForPID: PID
>> 3806201 does not belong to any known session
>
> Hrm, I don't see those, perhaps it is desktop or session manager
> specific somehow. I'm using i3 under lightdm.

It might be that my xterm is not started by i3.

I'm running i3 under gdm.

>> Somehow it still seems to work, however, so I'm not sure what to do
>> with those warnings...
>
> Me neither and I'm afraid upstream[0] has been dormant for several
> years so I'm rather reliant on contributions for issues people see
> which I don't.
>
> Perhaps
> https://bitbucket.org/raymonad/xss-lock/issues/13/allow-operation-as-systemd-user-unit#comment-45869112
> is useful, since they appear to be the author of the `-s` feature. And
> https://bitbucket.org/raymonad/xss-lock/issues/13/allow-operation-as-systemd-user-unit#comment-46751262
> then suggests using $XDG_SESSION_ID (but makes reference to having to
> export it somehow...).
>
> Worth a try I suppose, please let me know if it works and I'll update
> the service file in the package.

Okay, will try! I do see that XDG_SESSION_ID is a thing here...

> Out-of-interest how does one go about activating the service file for
> your user, I suppose you copy it to ~/.config somewhere or pass it to
> some systemctl command -- it'd be great if I could add some
> instructions to the docs.

The post above does a lot of legwork, but basically, this is my
.xsession:

#!/bin/sh

. ~/.shenv

# import the stuff from .shenv, above
systemctl --user import-environment

# ... in favor of this
exec systemctl --user start --wait xsession.target

# vincent bernat instead does this:
#
#     systemctl --user daemon-reload
#     exec systemctl --user start --wait i3.service
#
# ... which i find a bit bizarre: why don't we start the
# xsession.target instead? why reload the daemon?

Enjoy!

-- 
A riot is the language of the unheard.
                         - Martin Luther King, Jr.

[toc] | [prev] | [next] | [standalone]

#1076260

(sorry for the delay)

On Mon, 2021-09-27 at 09:27 -0400, Antoine Beaupré wrote:
> > Worth a try I suppose, please let me know if it works and I'll update
> > the service file in the package.
> 
> Okay, will try! I do see that XDG_SESSION_ID is a thing here...

Thanks.

> > Out-of-interest how does one go about activating the service file for
> > your user, I suppose you copy it to ~/.config somewhere or pass it to
> > some systemctl command -- it'd be great if I could add some
> > instructions to the docs.
> 
> The post above does a lot of legwork, but basically, this is my
> .xsession:

Thanks. It's probably a bit of a broad setup/concept for the xss-lock
docs but it's something I may try for myself at some point.

Ian.

[toc] | [prev] | [next] | [standalone]

#1076398

On 2021-10-17 07:31:09, Ian Campbell wrote:
> (sorry for the delay)
>
> On Mon, 2021-09-27 at 09:27 -0400, Antoine Beaupré wrote:
>> > Worth a try I suppose, please let me know if it works and I'll update
>> > the service file in the package.
>> 
>> Okay, will try! I do see that XDG_SESSION_ID is a thing here...
>
> Thanks.

And I can confirm it works, or at least does not warn.

>> > Out-of-interest how does one go about activating the service file for
>> > your user, I suppose you copy it to ~/.config somewhere or pass it to
>> > some systemctl command -- it'd be great if I could add some
>> > instructions to the docs.
>> 
>> The post above does a lot of legwork, but basically, this is my
>> .xsession:
>
> Thanks. It's probably a bit of a broad setup/concept for the xss-lock
> docs but it's something I may try for myself at some point.

Yeah, it's an emerging idea, and probably very niche, ie. restricted to
non-GNOME/KDE/etc sessions... But I still think it's kind of cool.

Oh, and xss-lock is awesome, thanks. Feels like a bit of too many moving
parts and I'm somewhat worried about it not working sometimes, but it's
much snappier than xscreensaver and "feels" a little more secure because
the way the components are setup.

And now that I think of it, I wonder if those processes couldn't be
better sandboxed... Ideas?

a.

-- 
When I came back to the United States, I decided that if you could use
propaganda for war, you could certainly use it for peace. And
"propaganda" got to be a bad word because of the Germans using it, so
what I did was to try and find some other words so we found the words
"public relations".      - Edward Bernays

[toc] | [prev] | [next] | [standalone]

#1077020

On Sun, 2021-10-17 at 19:07 -0400, Antoine Beaupré wrote:
> And I can confirm it works, or at least does not warn.

Excellent, thanks.

Is the diff as simple as:

   $ git diff
   diff --git a/doc/xss-lock.service b/doc/xss-lock.service
   index 52086c8..37d733e 100644
   --- a/doc/xss-lock.service
   +++ b/doc/xss-lock.service
   @@ -4,7 +4,7 @@ PartOf=graphical-session.target
    
    [Service]
    Type=simple
   -ExecStart=/usr/bin/xss-lock -l -s ${GRAPHICAL_SESSION_ID} -- i3lock
   +ExecStart=/usr/bin/xss-lock -l -s ${XDG_SESSION_ID} -- i3lock
    
    [Install]
    WantedBy=graphical-session.target
   
?

[toc] | [prev] | [next] | [standalone]

#1077058

[Multipart message — attachments visible in raw view] — view raw

On 2021-10-20 20:22:08, Ian Campbell wrote:
> On Sun, 2021-10-17 at 19:07 -0400, Antoine Beaupré wrote:
>> And I can confirm it works, or at least does not warn.
>
> Excellent, thanks.
>
> Is the diff as simple as:
>
>    $ git diff
>    diff --git a/doc/xss-lock.service b/doc/xss-lock.service
>    index 52086c8..37d733e 100644
>    --- a/doc/xss-lock.service
>    +++ b/doc/xss-lock.service
>    @@ -4,7 +4,7 @@ PartOf=graphical-session.target
>     
>     [Service]
>     Type=simple
>    -ExecStart=/usr/bin/xss-lock -l -s ${GRAPHICAL_SESSION_ID} -- i3lock
>    +ExecStart=/usr/bin/xss-lock -l -s ${XDG_SESSION_ID} -- i3lock
>     
>     [Install]
>     WantedBy=graphical-session.target

That sounds about right, here's my current service file.

-- 
Your injured body has become the burden of your digital soul.
                        - Yin Aiwen, 2013, The Massage is the Medium

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web