tvrzna / emptty

Dead simple CLI Display Manager on TTY
MIT License
696 stars 26 forks source link

listDesktops should follow symlinks (or use XDG_DATA_DIRS or a config option) #86

Closed the-argus closed 1 year ago

the-argus commented 1 year ago

I'm writing packaging and a module for nixOS, but on nixOS files like /usr/share/xsessions are symlinks (also they are located somewhere else, but that's a simple patch). As a result, these files don't show up to the listDesktops function in desktops.go, so I get "Not found any installed desktop."

The following is an implementation of filepath.walk with symlink following: https://github.com/facebookarchive/symwalk/blob/master/walk.go#L19

Alternatively, if you dont want to risk recursive symlinks crashing your program, you could add some way of specifying the location of xsessions and wayland-sessions at runtime.

tvrzna commented 1 year ago

Hello, thank you for maintaining emptty module for NixOS. I've tried your module, created PAM module and new directory /usr/share, then I've added symlink to /nix/store/...-desktops/share/xsessions and it works without any issues. I've also tried to make a test on my other Linux distro with symlinks and it read also symlink desktop file. Is there something I've missed?

I've checked proposed way to use XDG_DATA_DIRS and I'm not sure it would be good way - it contains too many of different paths (as it could grow with more installed modules). However the possibility to define custom path for xsessions and wayland-sessions is great idea.

the-argus commented 1 year ago

It's possible that I mis-diagnosed the problem, but it was the only explanation I could come up with. It's worth noting that under nixOS, the parent directories like share and xsessions are symlinks themselves, so it may be that emptty can read symlinked files but will not recurse into symlinked directories. Also, is this the module you used?

Maybe, if you have NixOS, you could clone my repo [github.com/the-argus/nixsys[(https://github.com/the-argus/nixsys/tree/365f0912ab5e955903e2c47bfd9f82b426b29749) at commit 365f0912ab5e955903e2c47bfd9f82b426b29749 and run `nixos-rebuild build-vm --flake .#laptop` and see if the problem is replicated? Otherwise maybe just do the custom path for sessions thing and I can just see if it works.

tvrzna commented 1 year ago

I think I don't have to use your repo, I can see it in last commit in packages/emptty/default.nix

sed -i "s|/usr/share/xsessions/|/etc/emptty/share/xsessions|g" src/desktop.go
sed -i "s|/usr/share/wayland-sessions/|/etc/emptty/share/wayland-sessions|g" src/desktop.go

If the path of symlink does not end with /, it simply does not follow the symlink. So you've diagnosed that just right, but the fix could be done easily.

However those config parameters will be done and will also watch for / at the end of path.

the-argus commented 1 year ago

Just updated. Got an error about needing getent in path. Restarted the emptty service. Now I get the following error:


Mar 16 22:50:04 evil emptty[22282]: PAM unable to dlopen(/nix/store/r5kfqrs5mgzcm35x0b2lq5grbdhlr1j4-linux-pam-1.5.2/lib/security/pam_u2f.so): /nix/store/r5kfqrs5mgzcm35x0b2lq5grbdhlr1j4-linux-pam-1.5.2/lib/sec>
Mar 16 22:50:04 evil emptty[22282]: PAM adding faulty module: /nix/store/r5kfqrs5mgzcm35x0b2lq5grbdhlr1j4-linux-pam-1.5.2/lib/security/pam_u2f.so
Mar 16 22:50:04 evil emptty[22282]: pam_succeed_if(emptty:auth): requirement "user ingroup nopasswdlogin" not met by user "argus"
Mar 16 22:50:18 evil emptty[22282]: gkr-pam: unable to locate daemon control file
Mar 16 22:50:18 evil emptty[22282]: gkr-pam: stashed password to try later in open session
Mar 16 22:50:18 evil emptty[22282]: pam_unix(emptty:session): session opened for user argus(uid=1000) by LOGIN(uid=0)
Mar 16 22:50:18 evil emptty[22282]: gkr-pam: unlocked login keyring
Mar 16 22:50:18 evil emptty[22282]: panic: runtime error: index out of range [6] with length 1
Mar 16 22:50:18 evil emptty[22282]: goroutine 1 [running, locked to thread]:
Mar 16 22:50:18 evil emptty[22282]: github.com/tvrzna/emptty/src.(*sysuser).getShell(0xc0000c8150?)
Mar 16 22:50:18 evil emptty[22282]:         github.com/tvrzna/emptty/src/sysuser.go:100 +0x118
Mar 16 22:50:18 evil emptty[22282]: github.com/tvrzna/emptty/src.(*commonSession).defineEnvironment(0xc0000b0140)
Mar 16 22:50:18 evil emptty[22282]:         github.com/tvrzna/emptty/src/session.go:142 +0x387
Mar 16 22:50:18 evil emptty[22282]: github.com/tvrzna/emptty/src.(*commonSession).start(0xc0000b0140)
Mar 16 22:50:18 evil emptty[22282]:         github.com/tvrzna/emptty/src/session.go:64 +0x4a
Mar 16 22:50:18 evil emptty[22282]: github.com/tvrzna/emptty/src.login(0xc0000b8000, 0xc0000a24c8)
Mar 16 22:50:18 evil emptty[22282]:         github.com/tvrzna/emptty/src/login.go:43 +0x34e
Mar 16 22:50:18 evil emptty[22282]: github.com/tvrzna/emptty/src.Main()
Mar 16 22:50:18 evil emptty[22282]:         github.com/tvrzna/emptty/src/emptty.go:39 +0xb7
Mar 16 22:50:18 evil emptty[22282]: main.main()
Mar 16 22:50:18 evil emptty[22282]:         github.com/tvrzna/emptty/main.go:6 +0x17```

Going to reboot now and see if it helps.
the-argus commented 1 year ago

the crash is gone, but i still got the user ingroup nopasswdlogin error, and the gkr-pam error. basically everything except the panic is still there. here is my /etc/emptty/conf:

ALWAYS_DBUS_LAUNCH=false
AUTOLOGIN=false
DBUS_LAUNCH=true
DEFAULT_SESSION=sway
DEFAULT_SESSION_ENV=wayland
DEFAULT_USER=argus
DYNAMIC_MOTD=false
DYNAMIC_MOTD_PATH=/etc/emptty/motd-gen.sh
ENABLE_NUMLOCK=false
HIDE_ENTER_LOGIN=false
HID_ENTER_PASSWORD=false
IDENTIFY_ENVS=false
MOTD_PATH=/etc/emptty/motd
PRINT_ISSUE=true
PRINT_MOTD=true
SWITCH_TTY=true
TTY_NUMBER=1
VERTICAL_SELECTION=false
WAYLAND_SESSIONS_PATH=/nix/store/89ajxrjzdb3xqbh4l42jawqjcz3wkapw-desktops/share/wayland-sessions/
XINITRC_LAUNCH=false
XORG_SESSIONS_PATH=/nix/store/89ajxrjzdb3xqbh4l42jawqjcz3wkapw-desktops/share/xsessions/
tvrzna commented 1 year ago

The first one with stack trace was a bug, when getenv passwd did not returned line for a user. It should be handled after last commit.

That user ingroup nopasswdlogin is more like info than error - it means, that PAM checks if the user is in nopasswdlogin group (for autologin without password). Since the user is not part of mentioned group, it proceed to next line (which means password authorization).

The gkr-pam lines are explained on the Arch Forum.

the-argus commented 1 year ago

added as of commit 89cbd2c