Using Ubuntu yakkety with polkit 0.113-4 from debian experimental (or 0.105-15 which does the same) and dbus-user-session enabled polkit-gnome-authentification-agent fails with a warning "Unable to determine the session we are in: No session for pid <nnn>" that seems an issue similar to https://bugs.freedesktop.org/show_bug.cgi?id=78905 but the packages contain the corresponding commit It looks polkitbackendsessionmonitor-systemd.c needs similar changes. We tried patching that locally but then the code hits a warning "Error getting subject: Error parsing unix-session subject: Didn't find value for key `session-id' of type s" and some gvariant errors
Thanks for your report. (In reply to Sebastien Bacher from comment #0) > Using Ubuntu yakkety with polkit 0.113-4 from debian experimental (or > 0.105-15 which does the same) and dbus-user-session enabled > polkit-gnome-authentification-agent fails with a warning "Unable to > determine the session we are in: No session for pid <nnn>" That should mean sd_pid_get_session(<nnn>) failed. > that seems an issue similar to > https://bugs.freedesktop.org/show_bug.cgi?id=78905 but the packages contain > the corresponding commit > > It looks polkitbackendsessionmonitor-systemd.c needs similar changes. “similar” to what?
similar to the changes done in bug #78905 https://cgit.freedesktop.org/polkit/commit/?id=a68f5dfd to try to use the display session if there is no login one
(In reply to Sebastien Bacher from comment #0) > It looks polkitbackendsessionmonitor-systemd.c needs similar changes. I don't understand. Kay's changes in the referenced commit, which I backported into 0.105-12, *are* to pbsm-systemd? Do you in fact mean that policykit-1-gnome, a separate source package that is superseded by gnome-shell in GNOME but might be used in other desktop environments like Unity, needs changes resembling the changes that were made to pbsm-systemd if it might get started outside the login-session? This bug report is missing clear steps-to-reproduce. Please at least paste systemd-cgls output from the failing situation, indicating which process was meant to be the parent of polkit-gnome-authentication-agent-1.
> I don't understand. Kay's changes in the referenced commit, which I backported > into 0.105-12, *are* to pbsm-systemd? No, sorry for the suboptimal description, here is a new description hopefuly less confusing Using Ubuntu yakkety and Unity, we are trying to migrate from upstart user session to systemd so we basically doing is - boot a yakkety daily - enable https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/systemd-session - install dbus-user-session and systemd-graphical-session - restart your session - start unity-control-center from the unity dash or an indicator, which are dbus activated and out of the logind session - try to unlock the user panel -> there is no auth prompt The reason seems to be that the polkit clients are started from outside the logind scope and hit that error "Unable to determine the session we are in: No session for pid <nnn>" the warning comes from src/polkit/polkitunixsession-systemd.c which looked like is doesn't handle sd_pid_get_session() similarly to the other bug/commit mentioned > Do you in fact mean that policykit-1-gnome, a separate source package that is > superseded by gnome-shell in GNOME but might be used in other desktop > environments like Unity, needs changes resembling the changes that were made > to pbsm-systemd if it might get started outside the login-session? That could be it yes, do you have a pointer to the "pbsm-systemd" changes? > This bug report is missing clear steps-to-reproduce. Please at least paste > systemd-cgls output from the failing situation, indicating which process was > meant to be the parent of polkit-gnome-authentication-agent-1. I think my comment about that was wrong, it's the other way around, the agent is active and working but the client code is not in the same scope which creates the issue
Created attachment 125140 [details] [review] tentative hack to polkitunixsession-systemd.c Using that change resolves the warning but gives a new one "Error getting subject: Error parsing unix-session subject: Didn't find value for key `session-id' of type s" the warning comes from polkit_backend_interactive_authority_register_authentication_agent() and it looks like polkit_subject_to_string(subject) is having a garbage session value
(In reply to Sebastien Bacher from comment #4) > That could be it yes, do you have a pointer to the "pbsm-systemd" changes? I was referring to <https://cgit.freedesktop.org/polkit/commit/?id=a68f5dfd>, and abbreviating the name of the file. > > This bug report is missing clear steps-to-reproduce. Please at least paste > > systemd-cgls output from the failing situation, indicating which process was > > meant to be the parent of polkit-gnome-authentication-agent-1. > > I think my comment about that was wrong, it's the other way around, the > agent is active and working but the client code is not in the same scope > which creates the issue In GNOME 3 on Debian, with dbus-user-session and a systemd-ized gnome-terminal, if I try to run polkit-gnome-authentication-agent-1 from a gnome-terminal, I get the same warning message. GNOME Shell's built-in authentication agent works fine, because GNOME Shell is run inside the login session; and I think Unity without systemd-graphical-session would behave similarly, because polkit-gnome-authentication-agent-1 would be started by XDG autostart (does Unity use gnome-session?) also inside the login session. I think the issue you're hitting is that you are going a step further than anything that's currently possible in Debian, and running your GUI shell (and its authentication agent) outside the login session as well?
Comment on attachment 125140 [details] [review] tentative hack to polkitunixsession-systemd.c Review of attachment 125140 [details] [review]: ----------------------------------------------------------------- ::: src/polkit/polkitunixsession-systemd.c @@ +469,5 @@ > } > > + /* Now do process -> uid -> graphical session (systemd version 213)*/ > + if (sd_pid_get_owner_uid (session->pid, &uid) < 0) > + goto out; This is incorrect, you will need to set the GError. @@ +473,5 @@ > + goto out; > + > + if (sd_uid_get_display (uid, &s) >= 0) > + { > + session->session_id = g_strdup (polkit_unix_session_new (s)); Er, strdup the session ID, not a PolkitUnixSession that wraps it?!
> does Unity use gnome-session? well, the session does use gnome-session but unity itself is a systemd user job, also the dash backend (which is what start softwares) is dbus activated, so technically it's out of the logind/gnome-session graphical session thanks for the patch review and sorry about the stupid strdup error that was a quick try before wrapping the detail should probably have postponed that to the next day
Created attachment 125188 [details] [review] use the correct id and display errors when needed Indeed works better without the thinko, that seems to do the trick, I'm going to play a bit more with it today to make sure though
Created attachment 125189 [details] [review] use the correct id and display errors when needed Indeed works better without the thinko, that seems to do the trick, I'm going to play a bit more with it today to make sure though
I confirm that this patch fixes polkit-gnome again with dbus-user-session. I applied it to the Debian package until it lands upstream, as this is blocking the adoption of dbus-user-session. Thanks!
I am affected by this bug with polkit 0.113 : when starting a polkit authentication agent (here polkit-gnome, but the kde counterpart seems to have the same behavior) from a user instance of systemd, I get this error message : Unable to determine the session we are in: No session for pid nnnn Starting the agent from a shell which is a child of the window manager works. Applying the patch in comment 10 solves the issue. Please consider merging it upstream.
Thanks, this looks okay to me, and it's gotten some testing (comment 11), so I'm pushing it to master now.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.