~mil/sxmo-tickets#567: 
sxmo_init.sh not respecting user defined $XDG_RUNTIME_DIR

I have noticed since this patch was added from sxmo_devel: Re: [PATCH sxmo-utils] Don't sucks while being used with logind

It doesn't respect user defined $XDG_RUNTIME_DIR, it is set but the services located under it fails to populate.

I have tried looking into this with the following but it didn't fix the issue, could have been from my error in the code.

diff --git a/configs/profile.d/sxmo_init.sh b/configs/profile.d/sxmo_init.sh index 1df829a..75faf55 100644 --- a/configs/profile.d/sxmo_init.sh +++ b/configs/profile.d/sxmo_init.sh @@ -40,15 +40,15 @@ _sxmo_find_runtime_dir() { if [ -n "$XDG_RUNTIME_DIR" ]; then printf %s "$XDG_RUNTIME_DIR" return

  • fi

  • if [ -d "/var/run/user/$(id -u)" ]; then

  • elif [ -d "/var/run/user/$(id -u)" ]; then printf "/var/run/user/%s" "$(id -u)" return
  • fi

    #Fallback to a shared memory location

  • printf "/dev/shm/user/%s" "$(id -u)"

  • else
  •   printf "/dev/shm/user/%s" "$(id -u)"
    
  • fi }

_sxmo_load_environments() {

Status
REPORTED
Submitter
~hazardchem
Assigned to
No-one
Submitted
1 year, 1 month ago
Updated
8 months ago
Labels
No labels applied.

~stacyharper 1 year, 1 month ago

Hey,

I have noticed since this patch was added from sxmo_devel: Re: [PATCH sxmo-utils] Don't sucks while being used with logind

It doesn't respect user defined $XDG_RUNTIME_DIR, it is set but the services located under it fails to populate.

I have tried looking into this with the following but it didn't fix the issue, could have been from my error in the code.

In which situation it does not respect it?

I don't really understand what this patch tries (and could) solve to be honnest.

~hazardchem 1 year, 1 month ago

In which situation it does not respect it?

I don't really understand what this patch tries (and could) solve to be honnest.

XDG_RUNTIME_DIR gets set to where I want it set to, in my case is /tmp/10000/ but, none of the files that are added such as the following: bonsai, dbus-1, dbus.bus, dconf, gvfs, gvfsd, pipewire-0, pipewire-0.lock, pulse, superd.lock, superd.sock, sway-ipc.10000.3672.sock, sxmo.led.lock, sxmo.state, sxmo.swaysock, sxmo.wobsock, sxmo_calls, sxmo_daemons, sxmobar, sxmobar.lock, wayland-1, wayland-1.lock

They all are added to either /var/run/user/10000, or /dev/shm/user/10000. And when my system looked for one of the files that is supposed to be under XDG_RUNTIME_DIR it has issues as there is nothing there, just a blank directory.

That patch I added was just an attempt that i tried to fix it but it failed to resolve the issue.

~stacyharper 1 year, 1 month ago

XDG_RUNTIME_DIR gets set to where I want it set to, in my case is /tmp/10000/ but, none of the files that are added such as the following: bonsai, dbus-1, dbus.bus, dconf, gvfs, gvfsd, pipewire-0, pipewire-0.lock, pulse, superd.lock, superd.sock, sway-ipc.10000.3672.sock, sxmo.led.lock, sxmo.state, sxmo.swaysock, sxmo.wobsock, sxmo_calls, sxmo_daemons, sxmobar, sxmobar.lock, wayland-1, wayland-1.lock

How do you set this up?

~hazardchem 1 year, 1 month ago

How do you set this up?

In my .profile with the following:

export XDG_RUNTIME_DIR="/tmp/$(id -u)" [ -d "${XDG_RUNTIME_DIR}" ] || ( mkdir -p "${XDG_RUNTIME_DIR}" chmod 0700 "${XDG_RUNTIME_DIR}" )

FYI this was working prior to the logind change.

~phartman REPORTED CLOSED 1 year, 19 days ago

this good now? reopen if still a problem.

~hazardchem 1 year, 19 days ago

Yep this is still occuring.

Would like it to be reopened.

~phartman CLOSED REPORTED 1 year, 18 days ago

~hazardchem 10 months ago

After revisiting https://lists.sr.ht/~mil/sxmo-devel/patches/40196 on a fresh install I can confirm this is being used now as I have it set in my profile.

~aren 10 months ago

I did a bit more research at some point and I think we should replace our xdg_runtime_dir handling with a pre-built solution that hooks into pam. Our solution doesn't get the permissions of the parent dir of xdg_runtime_dir right. It should be owned by root, but it's owned by the first user to log in, and any other user will get a permission denied error when sxmo_init tries to create xdg_runtime_dir. I don't think this would be easy to fix without some sort of privilege escalation in sxmo_init.sh which seems like a bad idea.

dumb_runtime_dir seems like a good option, but might need a little work to integrate into alpine without user configuration. pam-rundir and turnstile are other optinos, but are more complex / less well maintained. /etc/pam.d/base-session on alpine has a list of ones it looks for which was useful for finding these (and is probably where dumb_runtime_dir needs to be added).

~noneofyourbusiness 8 months ago

~hazardchem 8 months ago

Laughs in factotum (when I'm running it as a VM)

Register here or Log in to comment, or comment via email.