ignoring NEGOTIATE_UNIX_FD
Martin Vidner
mvidner at suse.cz
Mon Nov 5 08:09:17 PST 2012
On Sun, Nov 04, 2012 at 11:56:56PM +0100, Manuel Reimer wrote:
> So the next problem. My Idea was to create an "Inhibitor" from Perl.
>
> use strict;
> use Net::DBus qw(:typing);
>
> my $bus = Net::DBus->system;
> my $logind = $bus->get_service('org.freedesktop.login1');
> my $manager = $logind->get_object('/org/freedesktop/login1',
> 'org.freedesktop.login1.Manager');
> $manager->Inhibit('handle-power-key', 'testproc', 'testreason', 'block');
>
> Result:
>
> unknown type sig 'h' at
> /usr/lib/perl5/vendor_perl/Net/DBus/Binding/Introspector.pm line
> 810.
> I'm not interested in the return value, as the Inhibitor should run
> until my process ends (which closes all open file handles). So is
> there a simple way to just ignore the return value?
'h' is UNIX_FD, a newly added type, which is used in this API:
method QString org.freedesktop.login1.Manager.CreateSession(...[!],
QDBusUnixFileDescriptor& fd, ...)
You could avoid it by avoiding the introspection call, I don't know
whether the Perl bindings can do that. I maintain the Ruby bindings,
and received a similar report
https://github.com/mvidner/ruby-dbus/pull/23 with a stop-gap fix of
recognizing 'h' but not handing the actual file descriptors.
But it got me thinking, wasn't NEGOTIATE_UNIX_FD supposed to avoid
this, by not letting older bindings see what they cannot handle unless
they ask for it?
Should the bus keep track of h-ignorant clients and filter the
introspection data so that they don't see "poisonous" APIs?
Should the spec be clarified to say that clients should recognize
'h' (and other future extensions) and ignore it?
--
Martin Vidner, ruby-dbus maintainer
https://github.com/mvidner/ruby-dbus
Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20121105/f14eede0/attachment.pgp>
More information about the dbus
mailing list