Re: libsecret and dlopen/dlclose thread cleanup, dlopen freeze

[Emmanuele Bassi <ebassi gmail com>]

Not that I know of. Libsecret is a DBus wrapper around the shared
secret services provided by environments like GNOME (gnome-keyring)
and KDE (Kwallet); this usually implies that you're targeting either
of these environments, using their own DBus API (GDBus, for GNOME;
QtDBus for KDE).

Additionally, the python-dbus bindings used by that Python module use
the deprecated dbus-glib API, so I would not recommend using them
either.

Ciao,
 Emmanuele.


On 5 February 2017 at 15:19, Gábor Csárdi
<csardi gabor+gtk-list gmail com> wrote:
> Thanks much! This again saved me a lot of time and effort. OK, so I'll see
> what I can do with libdbus then.
>
> My last question. Do you know if anyone has even written a libsecret client
> on top of (lib)dbus only? The secretstorage Python module
> (https://github.com/mitya57/secretstorage) seems to do that, but it uses the
> Python dbus client, and I'll need to write everything in C.
>
> Thanks!
> Gabor
>
> On Sun, Feb 5, 2017 at 1:30 PM, Emmanuele Bassi <ebassi gmail com> wrote:
> > Hi;
> >
> > On 5 February 2017 at 12:51, Gábor Csárdi
> > <csardi gabor+gtk-list gmail com> wrote:
> > > Thanks! R is single threaded and synchronous (focus is computation, not
> > > I/O), so I don't need threaded code at all.
> >
> > Okay; just remember this in case you need to do asynchronous work.
> >
> > > Btw. I could also just have a dbus client using TCP/IP, right?
> >
> > No. The support for unauthenticated TCP connections is meant for
> > private connections, which means you would not be able to access the
> > session bus where the secrets manager lives.
> >
> > You'd need a special system configuration to allow TCP connections to
> > the session bus, but it's *strongly* discouraged to do so, unless you
> > want third parties to listen in to everything that gets sent through
> > the bus.
> >
> > Ciao,
> >  Emmanuele.
> >
> > > Gabor
> > >
> > > On Sun, Feb 5, 2017 at 11:36 AM, Emmanuele Bassi <ebassi gmail com>
> > > wrote:
> > > > Yes. Libdbus is a fairly low level API and has known limitations for
> > > > threaded code. It's the reference implementation of the DBus
> > > > specification,
> > > > and as such it should only be used if nothing else is available.
> > > >
> > > > Ciao,
> > > >  Emmanuele.
> > > >
> > > > On Sun, 5 Feb 2017 at 10:51, Gábor Csárdi
> > > > <csardi gabor+gtk-list gmail com> wrote:
> > > > > Thanks much, this saves me from a lot of trouble!
> > > > >
> > > > > I'll look at libdbus. That's probably a lot more work, I'll need to
> > > > > implement a small libsecret client, right?
> > > > >
> > > > > Thanks,
> > > > > Gabor
> > > > >
> > > > > On Sun, Feb 5, 2017 at 10:36 AM, Emmanuele Bassi <ebassi gmail com>
> > > > > wrote:
> > > > > > Hi;
> > > > > >
> > > > > > You cannot ever unload libgobject - and any other gobject based
> > > > > > libraries - with dlclose() after dlopen()-ing them. The type system
> > > > > > cannot
> > > > > > be reset on library unload, and thus types that were registered once
> > > > > > will
> > > > > > still be alive the next time you load the library. Additionally, GLib
> > > > > > and
> > > > > > GObject and GIO have threads and additional state created for things
> > > > > > like
> > > > > > GDBus, which libsecret uses internally to talk to the secrets
> > > > > > service.
> > > > > >
> > > > > > In short: if you want to have a plugin that talks to the password and
> > > > > > secret storage through the Secret Service DBus API, you will have to
> > > > > > use a
> > > > > > library that allows unloading and reloading; likely only libdbus.
> > > > > > Alternatively, do not allow disabling the plugin if you want to use
> > > > > > libsecret.
> > > > > >
> > > > > > Ciao,
> > > > > >  Emmanuele.
> > > > > >
> > > > > > On Sun, 5 Feb 2017 at 10:27, Gábor Csárdi
> > > > > > <csardi gabor+gtk-list gmail com> wrote:
> > > > > > > Hi all,
> > > > > > >
> > > > > > > I have a plugin that uses libsecret, and thus glib, on Linux. (It is
> > > > > > > a
> > > > > > > package for R.)
> > > > > > >
> > > > > > > It is loaded with dlopen(), and it (ideally) can be unloaded with
> > > > > > > dlclose(). I use the synchronous libsecret functions, which AFAICT
> > > > > > > run a
> > > > > > > temporary glib event loop for each libsecret query. E.g. this is
> > > > > > > what I am
> > > > > > > doing:
> > > > > > >
> > > > > > >   GError *err = NULL;
> > > > > > >
> > > > > > >   gchar *password = secret_password_lookup_sync (
> > > > > > >     keyring_secret_service_schema(),
> > > > > > >     /* cancellable = */ NULL,
> > > > > > >     &err,
> > > > > > >     "service", cservice,
> > > > > > >     "username", cusername,
> > > > > > >     NULL);
> > > > > > >
> > > > > > >   if (err) {
> > > > > > >     if (password) secret_password_free(password);
> > > > > > >     keyring_secret_service_handle_status("get", TRUE, err);
> > > > > > >   }
> > > > > > >
> > > > > > >   if (!password) {
> > > > > > >     error("keyring item not found");
> > > > > > >     return R_NilValue;
> > > > > > >
> > > > > > >   } else {
> > > > > > >     secret_password_free(password);
> > > > > > >     /* ... */
> > > > > > >     return result;
> > > > > > >   }
> > > > > > >
> > > > > > > When the lib is unloaded I call secret_service_disconnect(), I
> > > > > > > checked
> > > > > > > that this is called. I do link to libgobject-2.0, I even call
> > > > > > > g_type_ensure
> > > > > > > (G_TYPE_OBJECT) to make sure that the constructors in libgobject
> > > > > > > run.
> > > > > > >
> > > > > > > However, it seems that the worker threads for glib (?) are never
> > > > > > > cleaned up. Even if I dlclose() the lib, they are there. What am I
> > > > > > > missing
> > > > > > > here? Do I have to eliminate the threads manually? If yes, how can I
> > > > > > > do
> > > > > > > that?
> > > > > > >
> > > > > > > An even bigger problem is, that if I dlopen() the same plugin again,
> > > > > > > and call a libsecret function, then it just freezes with this:
> > > > > > >
> > > > > > > (process:18663): GLib-GObject-WARNING **: cannot register existing
> > > > > > > type
> > > > > > > 'SecretService'
> > > > > > > (process:18663): GLib-GObject-CRITICAL **:
> > > > > > > g_type_add_interface_static:
> > > > > > > assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed
> > > > > > > (process:18663): GLib-GObject-CRITICAL **:
> > > > > > > g_type_add_interface_static:
> > > > > > > assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed
> > > > > > > (process:18663): GLib-CRITICAL **: g_once_init_leave: assertion
> > > > > > > 'result
> > > > > > > != 0' failed
> > > > > > > (process:18663): GLib-GIO-CRITICAL **:
> > > > > > > g_async_initable_new_valist_async: assertion
> > > > > > > 'G_TYPE_IS_ASYNC_INITABLE
> > > > > > > (object_type)' failed
> > > > > > >
> > > > > > > Which seems to suggest that I need to unregister the SecretService
> > > > > > > type
> > > > > > > at dlclose(). Is that right? How can I do that?
> > > > > > >
> > > > > > > I don't have too much experience with glib, and I am just probably
> > > > > > > doing something wrong, or missing something. Any help is
> > > > > > > appreciated. I can
> > > > > > > also put together a reproducible example if needed.
> > > > > > >
> > > > > > > Thanks, Best,
> > > > > > > Gabor
> > > > > > > _______________________________________________
> > > > > > > gtk-list mailing list
> > > > > > > gtk-list gnome org
> > > > > > > https://mail.gnome.org/mailman/listinfo/gtk-list
> > > > > >
> > > > > > --
> > > > > > https://www.bassi.io
> > > > > > [@] ebassi [@gmail.com]
> > > > --
> > > > https://www.bassi.io
> > > > [@] ebassi [@gmail.com]
> >
> >
> >
> > --
> > https://www.bassi.io
> > [@] ebassi [@gmail.com]



-- 
https://www.bassi.io
[@] ebassi [@gmail.com]