[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: "not authorised" doing various desktoppy things [and 1 more messages]



On Wed, 04 Jan 2017 at 02:10:56 +0000, Ian Jackson wrote:
> Michael Biebl writes ("Re: "not authorised" doing various desktoppy things"):
> > Check if your session is marked as active and local
> > $ loginctl show-session $XDG_SESSION_ID
> 
> I see (amongst other things):
> 
>   Remote=no
>   Active=yes
>   State=active

Looks like the situation where polkit should allow most things.

If you were using the systemd service (and cgroup) manager, I'd ask you
to run `systemd-cgls` and/or `loginctl user-status` to visualize the
hierarchy of processes and cgroups that logind would use to match
processes to sessions, specifically looking for the process that you
think should be allowed to communicate with NetworkManager or udisks2
or other privileged services; but I don't know whether that works under
systemd-shim.

> I have frankly no idea what to expect from the
> communication between systemd-shim and systemd-logind

Mostly D-Bus, I think? Arranging for `dbus-monitor --system` to be run
as root and directed to a log before you log in might be useful. (To
work properly this requires at least stretch's version of dbus.)

> or even where to look for logs

If you were using systemd, the answer would be the Journal, or the
human-readable subset of the Journal that ends up in syslog. But you're
not, so I don't know. syslog? /proc/kmsg?

> I found this in my .xsession-errors:
> 
>  dbus-update-activation-environment: systemd --user not found, ignoring --systemd argument

That should be harmless: I don't think systemd-shim is meant to start
systemd --user.

If you were using the full systemd suite, logind would have asked the
system service manager (/lib/systemd/systemd, pid 1, uid 0) to start a
user service manager (/lib/systemd/systemd --user, pid > 1, your own
uid) on your behalf, and dbus-update-activation-environment would have
communicated with the user service manager to update its idea of what
the environment should be to include whatever came from your Xsession.d.
That's a secondary function: d-u-a-e's main job is to communicate with
dbus-daemon --session to do the same thing.

polkit interactions are about system-level functionality (pid 1,
dbus-daemon --system, *dm, PAM), and not about what happens among
an individual user's processes (systemd --user, dbus-daemon --session,
.xinitrc or equivalent).

    S


Reply to: