Using notify-send as a different user than the logged in user hangs

Sidekick · 2025-01-14 12:52:50

I'm trying to get notify-send to work when using it as a user that is not the logged in user. My DE is KDE. The issue is that notify-send just hangs for roughly a minute without doing anything and then returns.

I've tried this:

xhost +SI:localuser:someUser >/dev/null
sudo -u $someUser -i
export $(dbus-launch)
notify-send "Hello World"

and this in a Wayland session:

machinectl shell --uid=someUser --setenv=DISPLAY="${DISPLAY}" --setenv=NO_AT_BRIDGE=1 --setenv=XDG_SESSION_TYPE=wayland --setenv=XAUTHORITY="$XAUTHORITY" --setenv=QT_QPA_PLATFORM=wayland .host 
systemctl --user restart dbus
notify-send "Hello World"

and this in an X11 session:

xhost +SI:localuser:someUser >/dev/null
machinectl shell --uid=someUser --setenv=DISPLAY="${DISPLAY}" --setenv=NO_AT_BRIDGE=1 --setenv=XDG_SESSION_TYPE=x11 --setenv=XAUTHORITY="$XAUTHORITY" --setenv=QT_QPA_PLATFORM=xcb .host 
systemctl --user restart dbus
notify-send "Hello World"

note that in all three cases I'm able to launch

kate

or

firefox

without any issues, so the user does have access to the display server session.

Also in each case this is written in my journalctl:

Started dbus-:1.2-org.freedesktop.Notifications@0.service.
systemd[8047]: dbus-:1.2-org.freedesktop.Notifications@0.service: Main process exited, code=exited, status=1/FAILURE
systemd[8047]: dbus-:1.2-org.freedesktop.Notifications@0.service: Failed with result 'exit-code'.

When in a Wayland session I can also execute

/usr/lib/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland

and I get a full KDE desktop in a new window, running under someUser and I'm able to run notify-send commands without issue.

With my normal user, notify-send works fine. I'm not sure what I'm missing here.

Last edited by Sidekick (2025-01-14 12:59:10)

V1del · 2025-01-14 13:34:12

DBUS_SESSION_BUS_ADDRESS is the env you need from the user the notification daemon runs on (you don't need any of the other ones, your DISPLAY,XAUTHORITY,XDG_SESSION are completely irrelevant, the notification daemon runs on DBUS you need the DBUS_SESSION_BUS_ADDRESS). why are you trying to restart the dbus session, what are you hoping to achieve?

also smells XY, what's the actual purpose of this excercise what do you actually want to achieve as the end result: https://xyproblem.info

Last edited by V1del (2025-01-14 13:36:46)

Sidekick · 2025-01-14 13:47:09

V1del wrote:

DBUS_SESSION_BUS_ADDRESS is the env you need from the user the notification daemon runs on (you don't need any of the other ones, your DISPLAY,XAUTHORITY,XDG_SESSION are completely irrelevant, the notification daemon runs on DBUS you need the DBUS_SESSION_BUS_ADDRESS). why are you trying to restart the dbus session, what are you hoping to achieve?

notify-send is used by a program with a GUI I'm launching under someUser. From my understanding of dbus, I was under the impression that each logged in user needs to have their own session bus, hence me starting it. I don't think it's possible for multiple users to share the same session bus, even if it were isn't that insecure?

also smells XY, what's the actual purpose of this excercise what do you actually want to achieve as the end result: https://xyproblem.info

I'd like to run programs under a different user than my main user without having to logout and login from one user session to the other. I don't want the programs I run under someUser to have access to my documents, files and so on. The easiest way I found a couple years ago was using

sudo -u someUser -i

in combination with xhost. This worked fine until a program I started using - envision - turned out to be using send-notify, or - what is more likely - the same API that send-notify is using.

Edit:

Yep, as suspected if I try to use my main user's session bus address for someUser I get a permission denied error when using notify-send. Technically this is an improvement because it at least doesn't hang for a solid minute anymore. Maybe the easiest way would be to reduce the timeout to 1 second? I don't really understand why there is a timeout. It seems like whatever provides the notification dbus service is started the moment KDE is starting so having a timeout of any kind there seems unnecessary.

Last edited by Sidekick (2025-01-14 13:52:15)

V1del · 2025-01-14 14:01:46

For your usecase you should use proper sandboxing mechanisms that allow the file accesses you want to allow and deny a few others, while still allowing the normal user their access to the session bus, trying to clutch this into running different users in the same session is likely much more cumbersome than just wrapping it in a propperly configured firejail/flatpak or so.

As for insecurity considerations, you're already tearing a hole into that by allowing random users to access your users GUI/xorg session (well wayland should at least protect wayland clients from prying xwayland (xorg-x)eyes), adding DBUS to that should be the least of your concerns.

If it's just about making sure notifications are handled without a timeout, you could start a standalone notification daemon in your distinct DBUS session (you're unlikely to visibly see that in your real session however). https://wiki.archlinux.org/title/Deskto … Standalone

FWIW what happens with a simple and plain

sudo -u someUser DBUS_SESSION_BUS_ADDRESS=${DBUS_SESSION_BUS_ADDRESS} notify-send "Hello"

I'm fairly certain this worked the last time I tried such shenanigans.

Edit to your edit: The timeout isn't the notification daemon, but the fact that a tool tries to send a message over DBUS which isn't answered by anything, dbus timeouts default to 30s. And I'm not certain where - if at all - this is configurable.

Last edited by V1del (2025-01-14 14:09:01)

Sidekick · 2025-01-14 14:44:14

V1del wrote:

For your usecase you should use proper sandboxing mechanisms that allow the file accesses you want to allow and deny a few others, while still allowing the normal user their access to the session bus, trying to clutch this into running different users in the same session is likely much more cumbersome than just wrapping it in a propperly configured firejail/flatpak or so.

you aren't the first to recommend that, though there are some VR applications involved and VR on Linux is already finicky. Adding something like flatpak to the mix is going to involve a lot more research on my part and given that I have a solution that almost works I'd rather avoid that. Honestly aside from this notification stuff it's been fairly straight forward. We - as Linux users - use sudo already to become root, so becoming just another user was easy. I think the only thing I needed to find out was the xhost thing and with Wayland you don't even need that. At least I don't remember having to configure anything to make it work.

As for insecurity considerations, you're already tearing a hole into that by allowing random users to access your users GUI/xorg session (well wayland should at least protect wayland clients from prying xwayland (xorg-x)eyes), adding DBUS to that should be the least of your concerns.

I'm more concerned about a program trying to upload things. Having my home directory only be accessible to my user and its group and making sure that someUser isn't in that group is enough to prevent that from happening.

If it's just about making sure notifications are handled without a timeout, you could start a standalone notification daemon in your distinct DBUS session (you're unlikely to visibly see that in your real session however). https://wiki.archlinux.org/title/Deskto … Standalone

I thought about that but from reading further it seems like that might create a situation where DBUS wouldn't know which one to pick and get stuck again?

FWIW what happens with a simple and plain
sudo -u someUser DBUS_SESSION_BUS_ADDRESS=${DBUS_SESSION_BUS_ADDRESS} notify-send "Hello"
I'm fairly certain this worked the last time I tried such shenanigans.

same thing: Connection failed: No permission.

Edit to your edit: The timeout isn't the notification daemon, but the fact that a tool tries to send a message over DBUS which isn't answered by anything, dbus timeouts default to 30s. And I'm not certain where - if at all - this is configurable.

Are you sure? From reading the wiki article - same one you linked - dbus looks in ` /usr/share/dbus-1/services` for something that provides `org.freedesktop.Notifications` in my case that is the file cat org.kde.plasma.Notifications.service. This file has 3 lines:

[D-BUS Service]
Name=org.freedesktop.Notifications
Exec=/usr/bin/plasma_waitforname org.freedesktop.Notifications

If I take that last line and execute it on my normal user it returns immediately. If I execute it under someUser it gets stuck, just like using send-notify, and I get the same entries in my journalctl as if I had executed send-notify. That is what leads me to believe that this dbus service needs to somehow be initalized by something. That's why I included the plasma session start in my first post to show that it can be initialized under someUser but it isn't when using machinectl or just starting dbus.

Edit:

Reading up on dbus a bit, would it be possible to run the org.freedesktop.Notifications service on the system bus instead of the session bus?

Edit:

Found how to launch the KDE notifier manually

plasmawindowed org.kde.plasma.notifications

this however results in an error

qt.core.library: "/usr/lib/qt6/plugins/platforms/libqwayland-generic.so" loaded library
Failed to create wl_display (No such file or directory)
qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in "" even though it was found.

QT_QPA_PLATFORM is set to wayland so I'm not sure what it is complaining about.

Output of journalctl --user -f when executing the plasmawindowed command

systemd-coredump[94667]: [?] Process 94664 (plasmawindowed) of user 2002 dumped core.
                                                       
                                                       Stack trace of thread 94664:
                                                       #0  0x00007e8cef4a53f4 n/a (libc.so.6 + 0x963f4)
                                                       #1  0x00007e8cef44c120 raise (libc.so.6 + 0x3d120)
                                                       #2  0x00007e8cef4334c3 abort (libc.so.6 + 0x244c3)
                                                       #3  0x00007e8cefa905e8 n/a (libQt6Core.so.6 + 0x905e8)
                                                       #4  0x00007e8cefa91571 _ZNK14QMessageLogger5fatalEPKcz (libQt6Core.so.6 + 0x91571)
                                                       #5  0x00007e8cf00def8b n/a (libQt6Gui.so.6 + 0xdef8b)
                                                       #6  0x00007e8cf018bc18 _ZN22QGuiApplicationPrivate21createEventDispatcherEv (libQt6Gui.so.6 + 0x18bc18)
                                                       #7  0x00007e8cefb5727d _ZN23QCoreApplicationPrivate4initEv (libQt6Core.so.6 + 0x15727d)
                                                       #8  0x00007e8cf018bcae _ZN22QGuiApplicationPrivate4initEv (libQt6Gui.so.6 + 0x18bcae)
                                                       #9  0x00007e8cf0af94e6 _ZN19QApplicationPrivate4initEv (libQt6Widgets.so.6 + 0xf94e6)
                                                       #10 0x000058093aa80478 n/a (n/a + 0x0)
                                                       #11 0x00007e8cef434e08 n/a (libc.so.6 + 0x25e08)
                                                       #12 0x00007e8cef434ecc __libc_start_main (libc.so.6 + 0x25ecc)
                                                       #13 0x000058093aa80ff5 n/a (n/a + 0x0)
                                                       ELF object binary architecture: AMD x86-64
systemd[81823]: Started Launch DrKonqi for a systemd-coredump crash (PID 94668/UID 0).
drkonqi-coredump-launcher[94680]: Unable to find file for pid 94664 expected at "kcrash-metadata/plasmawindowed.869ab57f9caf4370a063c8639372eb29.94664.ini"
drkonqi-coredump-launcher[94680]: Nothing handled the dump :O

Last edited by Sidekick (2025-01-14 17:56:48)

Sidekick · 2025-01-14 18:32:29

Ok, solved. I had forgotten to allow someUser access to my user's Wayland socket and set the WAYLAND_DISPLAY variable. After doing that I was able to execute

plasmawindowed org.kde.plasma.notifications

which in turn allowed me in another session to send a notification with notify-send. It's not pretty but it works

The way I allow access to the Wayland socket is by using setfacl like this:

setfacl -m u:someUser:rx /run/user/1000
setfacl -m u:someUser:rwx /run/user/1000/wayland-0

When I'm done I remove these permission of course.

setfacl -x user:someUser /run/user/1000/wayland-0
setfacl -x user:someUser /run/user/1000

seth · 2025-01-15 11:07:37

Handing your second user the $DBUS_SESSION_BUS_ADDRESS of your main user and providing access to that bus (it's likely /run/user/1000/bus and 666, but /run/user/1000 is gonna be 700) should™ do for sending dbus messages - but now you're apparently also opening wayland (and X11) and I'd highly recommend to review the entire approach.

Either you're running the target process as your own user and use something like firejail to constrain its abilities or you're running the second session in a second (nested) display server or you're fine w/ no-gui and just need to send some messages to your main user where you'd want to use some system bus (wall or some custom fifo) for that specific communication.

Right now you're putting some effort into containing a process and then completely tear down those walls again. You could just as much skip the effort.

Sidekick · 2025-01-15 19:09:24

seth wrote:

Handing your second user the $DBUS_SESSION_BUS_ADDRESS of your main user and providing access to that bus (it's likely /run/user/1000/bus and 666, but /run/user/1000 is gonna be 700) should™ do for sending dbus messages

as I said, I tried it but it doesn't work. Right now each user has their own independent dbus session.

- but now you're apparently also opening wayland (and X11) and I'd highly recommend to review the entire approach.[...]

I'll read up on firejail. The nested display server is very easy to set up, however I'd have to look into how to set it up in a way that it integrates seamlessly into the existing session - think Virtualbox's seamless mode. We are getting very much off-topic though and I'm wondering why you are that concerned about this? I mean, I'm not complaining, just finding it a bit curious.

seth · 2025-01-15 20:58:04

Ah, the bus is SO_PEERCRED protected, https://unix.stackexchange.com/question … horization - you run into "connection closed" rather than a permission error for that.

I'm not concerned, just pointing out that you end up undermining your own goals here.
Firejail is "seamless" - you're still running everything as your own user, just with limited/moderated access to the wider system.

Arch Linux

#1 2025-01-14 12:52:50

Using notify-send as a different user than the logged in user hangs

#2 2025-01-14 13:34:12

Re: Using notify-send as a different user than the logged in user hangs

#3 2025-01-14 13:47:09

Re: Using notify-send as a different user than the logged in user hangs

#4 2025-01-14 14:01:46

Re: Using notify-send as a different user than the logged in user hangs

#5 2025-01-14 14:44:14

Re: Using notify-send as a different user than the logged in user hangs

#6 2025-01-14 18:32:29

Re: Using notify-send as a different user than the logged in user hangs

#7 2025-01-15 11:07:37

Re: Using notify-send as a different user than the logged in user hangs

#8 2025-01-15 19:09:24

Re: Using notify-send as a different user than the logged in user hangs

#9 2025-01-15 20:58:04

Re: Using notify-send as a different user than the logged in user hangs

Board footer