http://cgit.freedesktop.org/polkit/tree/src/polkitbackend/polkitbackendjsauthority.c?id=0.107#n730

Seems like a weird place to crash...

(In reply to comment #1)
> http://cgit.freedesktop.org/polkit/tree/src/polkitbackend/polkitbackendjsauthority.c?id=0.107#n730
> 
> Seems like a weird place to crash...

That it may be, but it is crashing on me. It is possible that some configuration or library version could cause it? My spidermonkey version is 1.8.5, and the only distro-specific configuration that Gentoo provides is /etc/polkit-1/rules.d/50-default.rules:

polkit.addAdminRule(function(action, subject) {
    return ["unix-user:0"];
});

I was able to dig a little deeper. The problem seems to be that, just when I select the GNOME user menu (top-right corner) in gnome-shell, the function subject_to_jsval:

http://cgit.freedesktop.org/polkit/tree/src/polkitbackend/polkitbackendjsauthority.c?id=0.107#n680

receives neither a PolkitUnixProcess nor a PolkitSystemBusName as a subject; it receives a PolitUnixSession (unix-session:3, according to polkit_unix_session_to_string). I believe the clicking on the GNOME user menu is important, since there it is the "Suspend/Power Off" option, so I guess gnome-shell queries polkitd to know if it is able to suspend the machine, somehow subject_to_jsval receives a PolkitUnixSession as subject, polkitd aborts:


http://cgit.freedesktop.org/polkit/tree/src/polkitbackend/polkitbackendjsauthority.c?id=0.107#n730

and gnome-shell displays only the "Power off" option. I see that PolkitUnixSession has a pid field, but it is write only; I wanted to extract it and set the pid variable with it, but as I said, it is write only. I added the following code:

--- a/src/polkitbackend/polkitbackendjsauthority.c
+++ b/src/polkitbackend/polkitbackendjsauthority.c
@@ -725,6 +725,10 @@ subject_to_jsval (PolkitBackendJsAuthority  *authority,
       pid = polkit_unix_process_get_pid (POLKIT_UNIX_PROCESS (process));
       g_object_unref (process);
     }
+  else if (POLKIT_IS_UNIX_SESSION (subject))
+    {
+	    return FALSE;
+    }
   else
     {
       g_assert_not_reached ();

but then polkitd crashes with a SEGV, according with systemd:

# systemctl status polkit.service
polkit.service - Authorization Manager
	  Loaded: loaded (/etc/systemd/system/polkit.service; static)
	  Active: failed (Result: signal) since Sat, 25 Aug 2012 15:43:53 -0500; 3s ago
	    Docs: man:polkit(8)
	 Process: 8354 ExecStart=/usr/lib/polkit-1/polkitd (code=killed, signal=SEGV)
	  CGroup: name=systemd:/system/polkit.service

If I return TRUE instead, polkitd does not crash, but then gnome-shell tells me that I can only Power off my machine, not suspend it.

So, several questions:

1. Why is my instance of polkitd (in two different machines) receiving a PolkitUnixSession as subject?
2. Why subject_to_jsval does not handle the case for receiving a PolkitUnixSession as subject?
3. Why returning FALSE from subject_to_jsval SEGV's polkitd?

From the logs of polkitd (running without --no-debug):


Sep 05 13:48:41 negra polkitd[413]: Successfully changed to user polkitd
Sep 05 13:48:41 negra polkitd[413]: Started polkitd version 0.107
Sep 05 13:48:41 negra polkitd[413]: Loading rules from directory /etc/polkit-1/rules.d
Sep 05 13:48:41 negra polkitd[413]: 13:48:41.500: Loading rules from directory /etc/polkit-1/rules.d
Sep 05 13:48:41 negra polkitd[413]: Loading rules from directory /usr/share/polkit-1/rules.d
Sep 05 13:48:41 negra polkitd[413]: 13:48:41.501: Loading rules from directory /usr/share/polkit-1/rules.d
Sep 05 13:48:41 negra polkitd[413]: Finished loading, compiling and executing 3 rules
Sep 05 13:48:41 negra polkitd[413]: 13:48:41.502: Finished loading, compiling and executing 3 rules
Sep 05 13:48:41 negra polkitd[413]: Entering main event loop
Sep 05 13:48:41 negra polkitd[413]: Connected to the system bus
Sep 05 13:48:41 negra polkitd[413]: Acquired the name org.freedesktop.PolicyKit1 on the system bus
Sep 05 13:48:41 negra polkitd[413]: 13:48:41.507: Acquired the name org.freedesktop.PolicyKit1 on the system bus
Sep 05 13:49:10 negra polkitd[413]: Registered Authentication Agent for unix-session:3 (system bus name :1.64 [/usr/bin/gnome-shell], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Sep 05 13:49:10 negra polkitd[413]: 13:49:10.575: Registered Authentication Agent for unix-session:3 (system bus name :1.64 [/usr/bin/gnome-shell], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Sep 05 14:05:36 negra polkitd[413]: **
Sep 05 14:05:36 negra polkitd[413]: ERROR:polkitbackendjsauthority.c:730:subject_to_jsval: code should not be reached

So it seems that gnome-shell it is categorized as a Unix session:

Registered Authentication Agent for unix-session:3 (system bus name :1.64 [/usr/bin/gnome-shell], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)

That would explain why the bug happened when I upgraded to gnome-shell 3.4.1.

Ping? I have been able to reproduce the same bug in polkit-0.106, and I took a look at gnome-shell source code. It turns out, gnome-shell registers itself as PolkitUnixSession:

http://git.gnome.org/browse/gnome-shell/tree/src/shell-polkit-authentication-agent.c?id=3.4.2#n106

Moreover, it has been doing this since 3.2 (at least). David, I see you marked as the author of this part of gnome-shell: could you please shed some light on this?

gnome-shell (as you wrote it) registers itself as PolkitUnixSession... and then polkit (as you wrote it in subject_to_jsval) refuses to deal with nothing that isn't PolkitUnixProcess or PolkitSystemBusName:

http://cgit.freedesktop.org/polkit/tree/src/polkitbackend/polkitbackendjsauthority.c?id=0.107#n730

As written in polkit-0.107, the three classes (PolkitUnixSession, PolkitUnixProcess, and PolkitSystemBusName) extend GObject, so there is no inheritance going on in the mix.

So either I'm not understanding something, or gnome-shell registers itself to polkit as a type that polkit itself would not deal with.

More info: before I looked at the code in gnome-shell-3.2, I tried to register gnome-shell as PolkitUnixProcess (since apparently this is covered by subject_to_jsval), and we have the PID available:


diff -burN gnome-shell-3.4.2/src/shell-polkit-authentication-agent.c gnome-shell-3.4.2-new/src/shell-polkit-authentication-agent.c
--- gnome-shell-3.4.2/src/shell-polkit-authentication-agent.c	2012-07-20 12:38:25.000000000 -0500
+++ gnome-shell-3.4.2-new/src/shell-polkit-authentication-agent.c	2012-09-13 13:05:55.414990107 -0500
@@ -103,23 +103,11 @@
   subject = NULL;
 
   error = NULL;
-  subject = polkit_unix_session_new_for_process_sync (getpid (),
-                                                      NULL, /* GCancellable* */
-                                                      &error);
+  subject = polkit_unix_process_new (getpid ());
+
   if (subject == NULL)
     {
-      if (error) /* polkit version 104 and older don't properly set error on failure */
-        {
-          g_warning ("Error getting session for the process we are in: %s (%s %d)",
-                     error->message,
-                     g_quark_to_string (error->domain),
-                     error->code);
-          g_error_free (error);
-        }
-      else
-        {
-          g_warning ("Error getting session for the process we are in");
-        }
+      g_warning ("Error getting session for the process we are in.");
       goto out;
     }

This fails; that doesn't surprise me. What surprises me is that (somehow) gnome-shell transforms to a PolkitUnixSession in the middle: I added printf's in subject_to_jsval using polkit_subject_to_string, and this is what I got:

13:30:18.852: Registered Authentication Agent for unix-process:2914:4149 (system bus name :1.89 [/usr/bin/gnome-shell], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.utf8)
>>>>>>>>>>>>>>system-bus-name::1.63
(a bunch of the above repeats several times).
>>>>>>>>>>>>>>unix-session:3
**
ERROR:polkitbackendjsauthority.c:733:subject_to_jsval: code should not be reached
Aborted

So (somehow) gnome-shell gets registered as unix-session even if I changed the code in gnome-shell; altough it does after being registered as unix-process in the first place. Maybe this is the root of the bug; somehow in Gentoo gnome-shell gets registered (no matter what) as unix-session, but I need a little help to dig deeper.

David, could you please at least point me in the right direction where to look?

OK, I got more info. I installed Gentoo in a QEMU VM (using gnome-boxes), because I'm using a modified Gentoo installation that only has systemd installed, not OpenRC (the default Gentoo init system). I wanted to see if I could reproduce the problem in a default Gentoo installation; the problem happens there too.

However, having a virtual machine to do tests helped me to find the following: If I disable systemd in the following packages:

gdm (--with-systemd=no)
gnome-session (--disable-systemd)
gnome-shell (--with-systemd=no)
polkit (--enable-libsystemd-login=no)

*THEN* the problem goes away. If even one of those four packages has support for systemd, the bug reappears.

In other words, if there is systemd support compiled in any of the packages related to the session handling in GNOME 3.4, then the bug appears. I'm running systemd/udev 189 (in Gentoo they are still instaleld separated).

I'm not sure anymore if the bug is in polkit, gnome-shell, gnome-session, gdm, systemd, or any possible combination of the above. If required, I can send a mail to systemd-devel.

I'll take a look at this tomorrow (on PTO today and traveling).

It seems that NetworkManager is also affected; even when compiled with --with-session-tracking=ck, somehow it misses the fact that the user is at the console, refusing to even introspect with gdbus.

--with-session-tracking=none didn't help. I had to manually edit /etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf and change <policy at_console="yes"> to <policy context="default">, even when ConsoleKit correctly reports that I'm at the console:

$ ck-list-sessions 
Session2:
	unix-user = '1000'
	realname = 'Canek Peláez Valdés'
	seat = 'Seat1'
	session-type = ''
	active = TRUE
	x11-display = ':0'
	x11-display-device = '/dev/tty1'
	display-device = ''
	remote-host-name = ''
	is-local = TRUE
	on-since = '2012-09-21T03:22:40.687833Z'
	login-session-id = '3'

I'm all for systemd tracking all user sessions, including GNOME's, but something in the Gentoo mix is failing to do it properly (I haven't seen any remotely similar to this bug in any other distro).

I have reasonable workarounds for all the problems I have found, but I would love to find the root issue.

Sorry for being slow. It seems to me that the root problem is that an application is passing a PolkitUnixSession to CheckAuthorization():

 http://www.freedesktop.org/software/polkit/docs/latest/eggdbus-interface-org.freedesktop.PolicyKit1.Authority.html#eggdbus-method-org.freedesktop.PolicyKit1.Authority.CheckAuthorization

method and the way we handle that is to crash. That's the problem, right?

If yes, I think the way to resolve this is to return an error if the @subject parameter isn't a PolkitUnixProcess or a PolkitSystemBusName.

I mean, it doesn't make much sense to ask if a whole session is authorized for an action ... if applications do that today already, they should probably be changed to ask for a specific process in the session.

It also sounds like you are using a system where "half" the system is using systemd for session tracking and the other "half" is using ConsoleKit. That won't work, obviously, you have to use one or the other.

(In reply to comment #9)
> Sorry for being slow. It seems to me that the root problem is that an
> application is passing a PolkitUnixSession to CheckAuthorization():
> 
>  http://www.freedesktop.org/software/polkit/docs/latest/eggdbus-interface-
> org.freedesktop.PolicyKit1.Authority.html#eggdbus-method-org.freedesktop.
> PolicyKit1.Authority.CheckAuthorization
> 
> method and the way we handle that is to crash. That's the problem, right?

I think so; I'm not really sure. I'm using basically only GNOME (3.4), and Gentoo has a couple of patches for it, but none of them (AFAICS) deals with authentication.

> If yes, I think the way to resolve this is to return an error if the
> @subject parameter isn't a PolkitUnixProcess or a PolkitSystemBusName.
> 
> I mean, it doesn't make much sense to ask if a whole session is authorized
> for an action ... if applications do that today already, they should
> probably be changed to ask for a specific process in the session.
> 
> It also sounds like you are using a system where "half" the system is using
> systemd for session tracking and the other "half" is using ConsoleKit. That
> won't work, obviously, you have to use one or the other.

That was my workaround, to disable systemd support for gnome-shell, gnome-session, gdm, and polkit. But the crash happens when any of the four has systemd   support (in particular, it happens when the four of them have systemd support). The only reason I had consolekit (before my workaround) was because accountsservice needed it (I'm using 6.22).

Now that you mentioned it, I can see that accountsservice 6.44 can use systemd also; I'm going to try it (disabling consolekit in everything else), and I will report the results.

Thanks.

(In reply to comment #10)
[snip]
> Now that you mentioned it, I can see that accountsservice 6.44 can use
> systemd also; I'm going to try it (disabling consolekit in everything else),
> and I will report the results.

OK, so yes, the culprit was consolekit (my fault; I didn't use the latest version for accountsservice). I now uninstalled consolekit, and nothing in my system depends on it, and now everything works, although polkitd keeps dying when I access the system menu, with the exact same message. However, it doesn't seem to affect the proper functioning of my system: I can suspend/resume my system, I can connect to wireless networks (without my hack), and I can mount/umount USB sticks.

It seems, as David, said that something is passing a PolkitUnixSession to CheckAuthorization(), so I suppose the error return would be a good idea (although my system works anyhow, it would be nice that polkitd didn't die every time I click the system menu).

Thanks, this was exactly the tip I needed to track down the problem.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/polkit/polkit/issues/42.