search

lxqt / lxqt-session

The LXQt session manager
https://lxqt.github.io
GNU Lesser General Public License v2.1
55 stars 52 forks source link

CustomProvider is never called from daemon #485

Closed gfgit closed 7 months ago

gfgit commented 7 months ago

This is a continuation of bug lxqt/lxqt-session#2496

Current behavior is to loop providers both inside lxqt-leave (user) and lxqt-session (daemon, root priviledge). They are tested in this order: (See lxqtpower.cpp#L41)

  1. CustomProvider
  2. LXQtProvider only if not called from daemon itself
  3. SystemdProvider
  4. UPowerProvider
  5. ConsoleKitProvider
  6. LxSessionProvider

So if CustomProvider succeeds from lxqt-leave, the daemon will never be called (lower priority) and it will never execute custom commands with root privileges. If CustomProvider fails, it will fail also if called by daemon soon after so again it will never be called with root privileges. This is because CustomProvider fails only if command cannot be started, it does not check command exit status, so it will always treat started commands as succeeded.

Now why should the code be duplicated if CustomProvider can never be called by lxqt-session if not by manually calling DBus without passing through lxqt-leave? This would also be inconsistent behavior in my opinion.

By swapping CustomProvider with LXQtProvider we run custom commands from daemon and if daemon is not running (is it always running?) then we execute them directly from lxqt-leave as user. This is same policy applied to other providers.

palinek commented 7 months ago

and lxqt-session (daemon, root priviledge).

I'm really surprised here. Does lxqt-session run as root on your side? If the answer is yes. How are then all other lxqt components spawned by lxqt-session dropping their privileges?

gfgit commented 7 months ago

My bad, I made the "daemon = root" equation. Without root privileges this topic becomes just a stylistic matter so I'm closing it. Sorry for the noise.