Launching sway from sddm

Launching sway from sddm

[Denis 'GNUtoo' Carikli]

[-- Attachment #1: Type: text/plain, Size: 3400 bytes --]

Hi,

I've installed Guix system i686 to a partition of my computer, and I'd
really like to be able to launch sway from something else than a tty to
reduce the attack surface.

If I launch sway from a tty, if either sway or swaylock[2] crashes, and
that the computer is left unattended (for a short moment), it would
then leave a shell open for potential attackers.

With a display manager, the attack surface is reduced to only swaylock,
which is much better.

Sway seems to work fine on x86_64 with gdm. But gdm is not available
anymore on i686[1].

So making sway work with sddm looks like a good approach to me.

So I've used the following sddm configuration:
> (service sddm-service-type
>  (sddm-configuration (display-server "wayland")))

And my user is declared like that:
> (user-account
>  (name "gnutoo")
>  (uid 1000)
>  (group "gnutoo")
>  (supplementary-groups '("audio" "netdev" "users" "video" "wheel")))

And with seatd configured in this way:
> (service seatd-service-type (seatd-configuration))
Or in this way:
> (service seatd-service-type
>  (seatd-configuration
>  (user "gnutoo")
>  (group "gnutoo")))
or with elogind declared in this way:
> (elogind-service)

Then once I login, the mouse pointer becomes a X like with the one in
Xorg -retro, and sway is never launched, but I can still go back in a
tty if I want.

And .local/share/sddm/wayland-session.log appears with the following
content:
> XDG_RUNTIME_DIR is not set in the environment. Aborting.

With the following instead:
> (service sddm-service-type
>  (sddm-configuration (display-server "x11")))
Then the display freezes and I can't go in a console anymore once I
tried to login in sddm.

I still managed to make it work manually in a strange way: I make sddm
use either elogind or seatd in my system.scm and then I would manually
login through a tty and become root and run seatd -u gnutoo -g
gnutoo, and once done, I can login in sway though sddm.

Before the seatd service was merged in Guix I managed to add a very
basic seatd service with no dependency, and having elogind + this seatd
service also worked. Now the merged seatd has dependencies and we end
up with the following error when adding both:
> guix system: error: service 'file-system-/sys/fs/cgroup' provided
> more than once

And according to people on #guix on liberachat, elogind and seatd aren't
supposed to be launched at the same time, so something looks strange
here.

I'm a bit lost here on what to do as I'm not familiar with elogind,
seatd, or even sddm.

Questions:
----------
- Is Xorg launched by SDDM? does it does it because sway fails?
- Where is XDG_RUNTIME_DIR supposed to be set?

And in general does someone has pointers on which direction to try to
look to debug that issue (to be able to get it fixed at some point)?

References:
-----------
[1]GDM now depends on rust, and bootstraping rust requires more than
   3GiB of memory. And with an i686 userspace and kernel, we have 3GiB
   of memory per process maximum, and with an x86_64 kernel and an i686
   rootfs we have 4GiB of memory per process maximum. At some point I
   managed to compile it under 4GiB but not yet under 3GiB.
[2]To launch swaylock I simply copied swaylock to ./ and I used chmod
   and chown to set ./swaylock setuid root, and then it would work fine.

Denis.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Launching sway from sddm

[(]

On Fri Jun 24, 2022 at 5:21 PM BST, Denis 'GNUtoo' Carikli wrote:
> - Is Xorg launched by SDDM? does it does it because sway fails?

I thought SDDM Wayland support didn't exist yet, but apparently I'm
wrong.

> - Where is XDG_RUNTIME_DIR supposed to be set?

XDG_RUNTIME_DIR is set by either elogind or greetd (which requires Rust)
iirc. You can also set it yourself in .profile or something:

--- .profile
export XDG_RUNTIME_DIR="/run/user/$(id -u)"
---

> And in general does someone has pointers on which direction to try to
> look to debug that issue (to be able to get it fixed at some point)?

Two things you might want to know:

(1) SDDM does not support seatd, only elogind:

--- /home/paren/code/guix/gnu/packages/display-managers.scm
(define-public sddm
  (package
    (inputs
     (list elogind #| if both were supported, it would use libseat, not
                      elogind |#))
---

(2) Sway does not officially support DMs, though GDM and greetd seem to
    work well, and Tobias (nckx) was using sway with SDDM if I remember
    correctly:

--- https://github.com/swaywm/sway/blob/master/README.md
Run sway from a TTY. Some display managers may work but are not
supported by sway (gdm is known to work fairly well).
---

    -- (

Re: Launching sway from sddm

[Timotej Lazar]

Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> [2022-06-24 18:21:26+0200]:
> If I launch sway from a tty, if either sway or swaylock[2] crashes, and
> that the computer is left unattended (for a short moment), it would
> then leave a shell open for potential attackers.

Don’t know about display managers, but I have been using `exec sway`
(previously `exec startx`) to avoid exposing a shell if sway crashes.

> [2]To launch swaylock I simply copied swaylock to ./ and I used chmod
>    and chown to set ./swaylock setuid root, and then it would work fine.

I add swaylock to setuid-programs in config.scm, which seems to work OK:

    (setuid-programs
     (cons*
      (setuid-program (program (file-append swaylock "/bin/swaylock")))
      %setuid-programs))

Re: Launching sway from sddm

[Denis 'GNUtoo' Carikli]

[-- Attachment #1: Type: text/plain, Size: 3504 bytes --]

On Fri, 24 Jun 2022 18:03:03 +0100
"(" <paren@disroot.org> wrote:
> On Fri Jun 24, 2022 at 5:21 PM BST, Denis 'GNUtoo' Carikli wrote:
> > - Where is XDG_RUNTIME_DIR supposed to be set?
[...]
> (1) SDDM does not support seatd, only elogind:

I've tried to workaround XDG_RUNTIME_DIR with a hack:
> --- a/gnu/system.scm
> +++ b/gnu/system.scm
> @@ -1173,6 +1173,8 @@ (define (operating-system-environment-variables
> os) ;; when /etc/machine-id is missing.  Make sure these warnings are
> non-fatal. ("DBUS_FATAL_WARNINGS" . "0")
>  
> +    ("XDG_RUNTIME_DIR" . "/run/user/1000")
> +
>      ;; XXX: Normally we wouldn't need to do this, but our glibc@2.23
> package ;; used to look things up in 'PREFIX/lib/locale' instead of
>      ;; '/run/current-system/locale' as was intended.  Keep this hack
> around so

And that now gives the following .local/share/sddm/wayland-session.log:
> 00:00:00.118 [ERROR] [wlr] [libseat] [libseat/backend/logind.c:317] Could not activate session: Interactive authentication required.
> 00:00:00.118 [ERROR] [wlr] [libseat] [libseat/libseat.c:79] No backend was able to open a seat
> 00:00:00.118 [ERROR] [wlr] [backend/session/session.c:84] Unable to create seat: Function not implemented
> 00:00:00.118 [ERROR] [wlr] [backend/session/session.c:218] Failed to load session backend
> 00:00:00.118 [ERROR] [wlr] [backend/backend.c:353] Failed to start a DRM session
> 00:00:00.118 [ERROR] [sway/server.c:53] Unable to create backend

And I also retried with sddm+seatd+manual-seatd instead of
sddm+elogind+manual-seatd and rebooted after that, and it didn't work so
I might have tested that wrong. The later still work though.

The first error is from libseat which is used by wlroots which
is used by sway:
> static int session_activate(struct backend_logind *session) {
>         sd_bus_message *msg = NULL;
>         sd_bus_error error = SD_BUS_ERROR_NULL;
> 
>         // Note: the Activate call might not make the session active
>         // immediately
>         int ret = sd_bus_call_method(session->bus,
>                                      "org.freedesktop.login1",
>                                      session->path,
>                                      "org.freedesktop.login1.Session",
>                                      "Activate",
>                                      &error, &msg, "");
>         if (ret < 0) { 
>                 log_errorf("Could not activate session: %s",
>                            error.message);
>         }
> 
>         sd_bus_error_free(&error);
>         sd_bus_message_unref(msg);
>         return ret;
> }
For this one I could look if we have the right methods on the session
dbus.

The second one is from libseat_open:
> struct libseat *libseat_open_seat([...]) {
>         [...]
> 
>         char *backend_type = getenv("LIBSEAT_BACKEND");
It first tries to get the backend from the environment.

And then if no LIBSEAT_BACKEND is set, it goes try all the backends
and returns the first valid one or prints the error we have:
> for (const struct named_backend *iter = impls; 
>      iter->backend != NULL;> iter++) {
>         backend = iter->backend->open_seat(listener, data);
>         if (backend != NULL) {
>                 log_infof("Seat opened with backend '%s'",
>                           iter->name);
>         return backend;
> }
> [...]
> log_error("No backend was able to open a seat");
> [...]
> return NULL;

Denis.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Launching sway from sddm

[Denis 'GNUtoo' Carikli]

[-- Attachment #1: Type: text/plain, Size: 267 bytes --]

Hi again,

I've tested with sddm and sway in Parabola i686 and it works, and the
configuration is the same between both, so maybe it's some parabola
specific configuration that is creating the issue.

I'll do more tests to find out what is the issue

Denis.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]