Sway: Sway 1.0-beta.1 freezes system on startup on void linux

[ghost]

• Sway Version: sway version 1.0-beta.1 (Oct 29 2018, branch 'HEAD')
• Debug Log: sway.log
• Configuration File: default

I compiled the latest release from github:

git clone https://github.com/swaywm/sway && cd sway
git checkout 1.0-beta.1
meson build
ninja -C build
sudo ninja -C build install
sudo chmod a+s /usr/local/bin/sway

Running sway causes the system to freeze.
SysRq does still work, however, which may mean that it is just crashing the graphics driver (I am not sure whether this is true, or how to test for it).

Extra info (I'm not sure whether any of this might be useful):

• I am running void linux with musl libc
• wlroots-devel is installed with xbps version wlroots-devel-0.1_2
• I have 2 GPU's (amd and nvidia)
  running with WLR_DRM_DEVICES to card0 or card1 set causes the program to return having found no GPUs swaycard.log even though they are is /dev/dri

$ ls /dev/dri
by-path card0 card1 renderD128 renderD129

• cards are using amdgpu and nouveau drivers respectivelly

$ lspci -nnk
07:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK208B [GeForce GT 710] [10de:128b] (rev a1)
    Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:8c93]
    Kernel driver in use: nouveau
    Kernel modules: nouveau
09:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Baffin [Radeon RX 460/560D / Pro 450/455/460/555/555X/560/560X] [1002:67ef] (rev e5)
    Subsystem: Gigabyte Technology Co., Ltd Device [1458:230a]
    Kernel driver in use: amdgpu
    Kernel modules: amdgpu

installed xbps driver versions are mesa-ati-dri-18.2.3_1 and mesa-nouveau-dri-18.2.3_1

[emersion]

It seems that sway crashes. Can you enable coredumps (if not already enabled) and post a backtrace (bt full in GDB)?

running with WLR_DRM_DEVICES to card0 or card1 set causes the program to return having found no GPUs swaycard.log even though they are is /dev/dri

Set this variable to the full path to cards, e.g. WLR_DRM_DEVICES=/dev/dri/card0

[ghost]

Even after enabling core dumps with ulimit -c unlimited sway does not produce a core dump when freezing the system. (I have verified core dumps are being produced for a different crashing program.)

I am going to sleep now; tomorrow I’ll try to ssh onto the machine after running sway to test if the system is working correctly apart from the graphics.

Setting WLR_DRM_DEVICES to the full path does work to isolate a single GPU, but selecting either, the system still becomes unresponsive.

[ddevault]

sway is presumably setuid on your system, you have to write 2 to /proc/sys/fs/suid_dumpable to enable coredumps for setuid programs.

[emersion]

Hmm. Actually this happens because drop_permissions fails (exit(EXIT_FAILURE)). From the logs:

Root privileges can be restored.

Instead, we should make drop_permissions return a bool indicating failure, and in this case cleanup the backend (that should fix the frozen VT issue).

But that won't make sway work. Are you running sway as root?

[Alphare]

I've actually had that very error message pop up once (I haven't had time to do a proper bug report yet). What does "Root privileges can be restored. Refusing to start." really mean? Why do we refuse to start?
Thanks

[emersion]

When you don't have logind, sway needs root privileges to become DRM master. In this situation, we start as root, become DRM master and then drop privileges. However sometimes dropping root fails. Instead of running the whole compositor as root, we prefer to fail.

[ghost]

@SirCmpwn yes you're right - I should've read the man page more carefully, however even with the correct configuration no core dump is produced still. I think @emersion is right in what is happening.

The program is still able to regain root permissions after dropping them. I wrote this piece of code to investigate this behavior. I created the setuid executable with

gcc setuidtest.c -o setuidtest
sudo chown root:root setuidtest
sudo chmod u+s setuidtest

and I can indeed reproduce that my program is able to regain root permissions.
I would appreciate if someone else could try to run it to verify whether it is just a quirk with my machine.

[ghost]

I am also definitely not running the program as root.
EDIT: To avoid confusion, what I meant was that the RUID is not root.

$ id
uid=1000(antek) gid=1000(antek) groups=1000(antek),4(wheel),12(audio),13(video)

$ stat $(which sway)
  File: /usr/local/bin/sway
  Size: 3182384     Blocks: 6216       IO Block: 4096   regular file
Device: 804h/2052d  Inode: 6177135     Links: 1
Access: (6755/-rwsr-sr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2018-10-29 18:53:48.347007172 +0000
Modify: 2018-10-29 18:52:57.850012581 +0000
Change: 2018-10-29 18:53:15.584010681 +0000
 Birth: -

[ddevault]

Your stat says differently, this binary is setuid, owned by uid 0, and therefore runs as root.

[ghost]

I don't use logind and therefore, according to your installation guide, I need to setuid the binary.
If i remove the setuid bit, sway fails to run because it doesn't have CAP_SYS_ADMIN.

[ddevault]

setuid is the correct procedure in this situation. But as a consequence, the procedure for obtaining a core dump and corresponding stack trace changes.

[ghost]

Yes, you're right. What I meant was that I am not running the program with the real UID of root, so it should be able to drop priviledges normally (as opposed to running it with sudo, where setuid(getuid()) wouldn't drop them).

The procedure I followed to try to get the core dump of the program was

ulimit -c unlimited
echo 2 | sudo tee /proc/sys/fs/suid_dumpable
echo /root/core | sudo tee /proc/sys/kernel/core_pattern
sway -d

Again, no core dump was produced which suggests that the program exited instead of crashing (as @emersion mentioned).

[emersion]

It's expected that no coredump is produced, since sway doesn't crash but exits with a non-zero status code. Here is the exact codepath:

https://github.com/swaywm/sway/blob/d3a62633113d487b5a5b1b484736dbe7cbe26bd0/sway/main.c#L210

[emersion]

Tried your piece of code on my machine, here is the output:

real: 1000 eff: 1000 saved: 1000
Dropped root priviledges
real: 1000 eff: 1000 saved: 1000
Unable to recover root
real: 1000 eff: 1000 saved: 1000

And here is the stat:

  File: a.out
  Size: 16848       Blocks: 40         IO Block: 4096   regular file
Device: 2eh/46d Inode: 506522      Links: 1
Access: (4755/-rwsr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2018-10-30 18:52:26.769807762 +0100
Modify: 2018-10-30 18:51:56.963093513 +0100
Change: 2018-10-30 18:52:25.009804898 +0100
 Birth: -

[ghost]

@emersion thanks! What's interesting, on your machine the effective uid starts out as that of your user (unlike mine, where it is already 0). Could you try out this version which explicitly setuid's to 0 (and still fails on my pc).
My output for reference:

real: 1000 eff: 0 saved: 0
Gained root priviledges
real: 1000 eff: 0 saved: 0
Dropped root priviledges
real: 1000 eff: 1000 saved: 1000
ERROR Still able to recover root
real: 0 eff: 0 saved: 0

[catb0t]

I'm not sure this will make a difference but this version attempts to make setuid and getuid syscalls directly, bypassing glibc / musl libc (hopefully). If musl libc has a bug or different behaviour in setuid, this should expose it.

Is the output of that any different for you? My output with both the libc and syscall code is

real: 1000 eff: 0 saved: 0
Gained root priviledges
real: 1000 eff: 0 saved: 0
Dropped root priviledges
real: 1000 eff: 1000 saved: 1000
Unable to recover root
real: 1000 eff: 1000 saved: 1000

[ghost]

@catb0t thanks for the program, but unfortunatelly the output produced is still the same. In fact, I managed to reproduce the same issue with a piece of assembler code which only performed the mentioned setuid calls. I think this is a problem with my kernel and will report it to the void developers.

As for sway, if I comment the last check out and recompile the code, it seems to work just fine.
Therefore, I suggest to close this issue as the problem is beyond the scope of sway.

[logol]

I had nearly the same problem (freezed system after sway binary execution on void linux from tty), but my binaries are built with glib

I solved the issue by setting up required XDG variables (https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html), especially XDG_RUNTIME_DIR (others may be required too, e.g. for starting alacritty inside sway)
people on void linux should have a look here https://wiki.voidlinux.eu/Wayland

quick fix, before starting sway: export XDG_RUNTIME_DIR=/tmp/${UID}-runtime-dir && mkdir $XDG_RUNTIME_DIR

[ghost]

@logol quite interestingly this issue did turn out to come partly from XDG_RUNTIME_DIR. What I used to set this envvar up was pam_rundir.so, which turned out to set capabilities making it impossible to successfully drop root (namely SECBIT_NO_SETUID_FIXUP) because of a Void-specific patch!