feat(greetd): use greetd instead of sddm

[HerrNaN]

After adding greetd, gtkgreet along with a sample config for this combination from the wiki it still doesn't work.

When looking into the logs I see:

...
fedora greetd[1444]: error: configured default session user `greeter` is not found
...

Some further investigation shows me that the greeter user doesn't exist on the system and when trying to create it like so: sudo useradd -M -G video greeter I get an error saying the video group doesn't exist either.

[HerrNaN]

I read that the video group is a pre-systemd thing and thought that could maybe explain why the system doesn't have it, so I tried adding the user without the video group. This got me past the previous problem but into a new one: we don't have cage installed on the system.

Since we will need to add cage for this purpose only, and it could run with sway instead (which we already have installed) I think we should look into running the greeter with sway instead.

[HerrNaN]

Seems like using cage or sway with the user setup as described above works for starting the greeter. However both suffer from the same problem when the greeter in turn wants to start the user session, dropping you into a black screen with the following error message:

unable to set working directory: No such file or directory (os error 2)

I am yet to find out exactly what 'file or directory' it is referring to.

Note: the black screen in question doesn't allow you to switch tty so reboot seems like the only option to get out of the situation.

[HerrNaN]

Are we running SELinux because that is known to block greetd?

[williamleven]

https://www.reddit.com/r/Fedora/comments/kjyhnh/merry_christmas_and_how_to_use_greetd_in_fedora/

[williamleven]

https://github.com/ostreedev/ostree-rs-ext/issues/510

[HerrNaN]

Two ways to go here as of now:

1. Disable SELinux (tempting, but let's not throw it out as soon as it get a little windy)
2. Apply the workaround mentioned here

I have tested the workaround locally (see below) and it solves our problem. It also appears consistent across boots, which is nice!

The workaround:

sudo cp /usr/bin/greetd /usr/local/bin/greetd
sudo mount --bind /usr/local/bin/greetd /usr/bin/greetd
sudo semanage fcontext -a -t xdm_exec_t /usr/bin/greetd
sudo restorecon /usr/bin/greetd

It seems that the reason it is consistent (although the mount isn't) is because the new binary that was created just so happens to live in a directory that appears earlier in the systemd users PATH. This should imply that the mount part of the workaround in our situation is unnecessary.