Web lists-archives.com

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




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@xxxxxxxxx> 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@xxxxxxxxx> wrote:
>>
>> Hi;
>>
>> On 5 February 2017 at 12:51, Gábor Csárdi
>> <csardi.gabor+gtk-list@xxxxxxxxx> 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@xxxxxxxxx>
>> > 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@xxxxxxxxx> 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@xxxxxxxxx>
>> >>> 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@xxxxxxxxx> 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@xxxxxxxxx
>> >>>>> 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]
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list