Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#823914: gtk3-nocsd: error message with 32-bit applications on amd64
89 views
Skip to first unread message
Vincent Lefevre
May 10, 2016, 7:30:03 AM5/10/16
to
Package: gtk3-nocsd
Version: 2-1
Severity: normal
After compiling a program with "gcc -m32", running this program
yields:
ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
on stderr. This is an annoying error message, which can also break
scripts that check error output.
gtk3-nocsd should be as transparent as possible.
-- System Information:
Debian Release: stretch/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.5.0-2-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages gtk3-nocsd depends on:
ii libgtk3-nocsd0 2-1
gtk3-nocsd recommends no packages.
gtk3-nocsd suggests no packages.
-- no debconf information
Version: 2-1
Severity: normal
After compiling a program with "gcc -m32", running this program
yields:
ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
on stderr. This is an annoying error message, which can also break
scripts that check error output.
gtk3-nocsd should be as transparent as possible.
-- System Information:
Debian Release: stretch/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.5.0-2-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages gtk3-nocsd depends on:
ii libgtk3-nocsd0 2-1
gtk3-nocsd recommends no packages.
gtk3-nocsd suggests no packages.
-- no debconf information
Christian Seiler
May 10, 2016, 7:50:03 AM5/10/16
to
Control: retitle -1 gtk3-nocsd: secondary arch libraries aren't
installed by default, causes unnecessary warnings
Control: tags -1 + confirmed help
Am 2016-05-10 13:24, schrieb Vincent Lefevre:
> After compiling a program with "gcc -m32", running this program
> yields:
>
> ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be
> preloaded (cannot open shared object file): ignored.
>
> on stderr. This is an annoying error message, which can also break
> scripts that check error output.
Yes, so the problem is that gtk3-nocsd sets
LD_PRELOAD=libgtk3-noscd.so.0.
That means that ld.so tries to preload the library - and there's
currently
now way of telling ld.so to not print an error and simply ignore and
entry
in LD_PRELOAD if it can't load it. (And you only have the amd64 version
installed.)
(For this reason the library is installed as mode 4644, to make ld.so
preload it even if the binary is setuid/setgid/has fscaps, otherwise
you'd
get the same message everytime you type 'ping' or 'su'. See the lintian
overrides of the package.)
gtk3-nocsd is Multi-Arch-aware though: you can install the
libgtk3-nocsd0
package on i386 (in addition to the native arch one that's already
installed on your system) and the message will disappear. (gtk3-nocsd is
Arch: all, libgtk3-nocsd0 is Arch: any and M-A: same.)
Unfortunately, I have no good solution how to improve that:
> gtk3-nocsd should be as transparent as possible.
I agree fully - but I don't really see a good way how to solve it.
1. There's no Depends/Recommends: pkg:all-enabled-archs in APT
2. There's no way of telling ld.so "yeah, it's fine if this LD_PRELOAD
fails, just try it and if it doesn't work silently ignore it"
I could of course add a postinst debconf prompt to gtk3-nocsd so that if
multiple architectures are installed, but gtk3-nocsd isn't, the user
gets
a message and is asked to install libgtk3-nocsd0 for the other archs.
Would that be something you'd be OK with?
Do you have any other ideas?
Regards,
Christian
installed by default, causes unnecessary warnings
Control: tags -1 + confirmed help
Am 2016-05-10 13:24, schrieb Vincent Lefevre:
> After compiling a program with "gcc -m32", running this program
> yields:
>
> ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be
> preloaded (cannot open shared object file): ignored.
>
> on stderr. This is an annoying error message, which can also break
> scripts that check error output.
LD_PRELOAD=libgtk3-noscd.so.0.
That means that ld.so tries to preload the library - and there's
currently
now way of telling ld.so to not print an error and simply ignore and
entry
in LD_PRELOAD if it can't load it. (And you only have the amd64 version
installed.)
(For this reason the library is installed as mode 4644, to make ld.so
preload it even if the binary is setuid/setgid/has fscaps, otherwise
you'd
get the same message everytime you type 'ping' or 'su'. See the lintian
overrides of the package.)
gtk3-nocsd is Multi-Arch-aware though: you can install the
libgtk3-nocsd0
package on i386 (in addition to the native arch one that's already
installed on your system) and the message will disappear. (gtk3-nocsd is
Arch: all, libgtk3-nocsd0 is Arch: any and M-A: same.)
Unfortunately, I have no good solution how to improve that:
> gtk3-nocsd should be as transparent as possible.
1. There's no Depends/Recommends: pkg:all-enabled-archs in APT
2. There's no way of telling ld.so "yeah, it's fine if this LD_PRELOAD
fails, just try it and if it doesn't work silently ignore it"
I could of course add a postinst debconf prompt to gtk3-nocsd so that if
multiple architectures are installed, but gtk3-nocsd isn't, the user
gets
a message and is asked to install libgtk3-nocsd0 for the other archs.
Would that be something you'd be OK with?
Do you have any other ideas?
Regards,
Christian
Vincent Lefevre
May 10, 2016, 8:50:05 AM5/10/16
to
On 2016-05-10 13:41:14 +0200, Christian Seiler wrote:
> Am 2016-05-10 13:24, schrieb Vincent Lefevre:
> > After compiling a program with "gcc -m32", running this program
> > yields:
> >
> > ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be
> > preloaded (cannot open shared object file): ignored.
> >
> > on stderr. This is an annoying error message, which can also break
> > scripts that check error output.
>
> Yes, so the problem is that gtk3-nocsd sets LD_PRELOAD=libgtk3-noscd.so.0.
> That means that ld.so tries to preload the library - and there's currently
> now way of telling ld.so to not print an error and simply ignore and entry
> in LD_PRELOAD if it can't load it. (And you only have the amd64 version
> installed.)
This would have been the best solution (I never need the library
> Am 2016-05-10 13:24, schrieb Vincent Lefevre:
> > After compiling a program with "gcc -m32", running this program
> > yields:
> >
> > ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be
> > preloaded (cannot open shared object file): ignored.
> >
> > on stderr. This is an annoying error message, which can also break
> > scripts that check error output.
>
> Yes, so the problem is that gtk3-nocsd sets LD_PRELOAD=libgtk3-noscd.so.0.
> That means that ld.so tries to preload the library - and there's currently
> now way of telling ld.so to not print an error and simply ignore and entry
> in LD_PRELOAD if it can't load it. (And you only have the amd64 version
> installed.)
for 32-bit programs, I just want to avoid the error message).
> (For this reason the library is installed as mode 4644, to make ld.so
> preload it even if the binary is setuid/setgid/has fscaps, otherwise you'd
> get the same message everytime you type 'ping' or 'su'. See the lintian
> overrides of the package.)
gtk3-nocsd, just to avoid an error message? Perhaps in the long term,
ld.so should provide a way to avoid error messages due to non-matching
permissions or ELF class.
> gtk3-nocsd is Multi-Arch-aware though: you can install the libgtk3-nocsd0
> package on i386 (in addition to the native arch one that's already
> installed on your system) and the message will disappear. (gtk3-nocsd is
> Arch: all, libgtk3-nocsd0 is Arch: any and M-A: same.)
just depends on libc6 (it would have been different if it brought lots
of dependencies).
Now, this would mean that one has to enable i386, which is normally
not necessary for "gcc -m32" if one just uses the C library because
the C library is currently special (one just needs libc6-dev-i386
and libc6-i386, on which packages like gcc-5-multilib depend).
> Unfortunately, I have no good solution how to improve that:
>
> > gtk3-nocsd should be as transparent as possible.
>
> I agree fully - but I don't really see a good way how to solve it.
>
> 1. There's no Depends/Recommends: pkg:all-enabled-archs in APT
enabled (see above) or it could be enabled later.
> 2. There's no way of telling ld.so "yeah, it's fine if this LD_PRELOAD
> fails, just try it and if it doesn't work silently ignore it"
>
> I could of course add a postinst debconf prompt to gtk3-nocsd so that if
> multiple architectures are installed, but gtk3-nocsd isn't, the user gets
> a message and is asked to install libgtk3-nocsd0 for the other archs.
> Would that be something you'd be OK with?
> Do you have any other ideas?
abandoned.
Perhaps provide a 32-bit library for the amd64 package? But one should
still make sure that packages in both arch are coinstallable.
If there is no good solution, some note should be added to the
/usr/share/doc/gtk3-nocsd/README.Debian file, hoping that if the
user gets the error message, he would look at this file.
--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Christian Seiler
May 10, 2016, 9:20:03 AM5/10/16
to
Am 2016-05-10 14:41, schrieb Vincent Lefevre:
> On 2016-05-10 13:41:14 +0200, Christian Seiler wrote:
>> Yes, so the problem is that gtk3-nocsd sets
>> LD_PRELOAD=libgtk3-noscd.so.0.
>> That means that ld.so tries to preload the library - and there's
>> currently
>> now way of telling ld.so to not print an error and simply ignore and
>> entry
>> in LD_PRELOAD if it can't load it. (And you only have the amd64
>> version
>> installed.)
>
> This would have been the best solution
I agree. Maybe I should open a bug report against libc...
> On 2016-05-10 13:41:14 +0200, Christian Seiler wrote:
>> Yes, so the problem is that gtk3-nocsd sets
>> LD_PRELOAD=libgtk3-noscd.so.0.
>> That means that ld.so tries to preload the library - and there's
>> currently
>> now way of telling ld.so to not print an error and simply ignore and
>> entry
>> in LD_PRELOAD if it can't load it. (And you only have the amd64
>> version
>> installed.)
>
> This would have been the best solution
>> (For this reason the library is installed as mode 4644, to make ld.so
>> preload it even if the binary is setuid/setgid/has fscaps, otherwise
>> you'd
>> get the same message everytime you type 'ping' or 'su'. See the
>> lintian
>> overrides of the package.)
>
> Couldn't this be a security issue in case there is a potential bug in
> gtk3-nocsd, just to avoid an error message?
consequences,
and for there to be a security issue would mean that the called binary
needs to load a shared library with a symbol with the same name as those
that gtk3-nocsd exports, and the user needs to be able to influence the
code that calls that function to pass it some weird input AND there has
to
be a bug in gtk3-nocsd that is exploitable. I'm not saying that there's
no
risk to it, but the attack surface is really low here, compared to a lot
of other stuff that can go wrong in privileged programs. (Especially
since
the routines that gtk3-nocsd overrides have nothing to do at all with
user
input.)
> Perhaps in the long term,
> ld.so should provide a way to avoid error messages due to non-matching
> permissions or ELF class.
like
"please try this. If it doesn't work, don't worry, just continue, don't
say anything".
> Perhaps provide a 32-bit library for the amd64 package? But one should
> still make sure that packages in both arch are coinstallable.
easily have the same issue (e.g. arm64 system with some 32bit armhf
binaries) in principle. (Although I don't know if arm64 has multilib or
only supports real multiarch.)
> If there is no good solution, some note should be added to the
> /usr/share/doc/gtk3-nocsd/README.Debian file, hoping that if the
> user gets the error message, he would look at this file.
Regards,
Christian
Vincent Lefevre
May 10, 2016, 9:50:03 AM5/10/16
to
On 2016-05-10 15:12:43 +0200, Christian Seiler wrote:
> Am 2016-05-10 14:41, schrieb Vincent Lefevre:
> > On 2016-05-10 13:41:14 +0200, Christian Seiler wrote:
> > > Yes, so the problem is that gtk3-nocsd sets
> > > LD_PRELOAD=libgtk3-noscd.so.0.
> > > That means that ld.so tries to preload the library - and there's
> > > currently
> > > now way of telling ld.so to not print an error and simply ignore and
> > > entry
> > > in LD_PRELOAD if it can't load it. (And you only have the amd64
> > > version
> > > installed.)
> >
> > This would have been the best solution
>
> I agree. Maybe I should open a bug report against libc...
Yes. BTW, the LD_PRELOAD description in the ld.so(8) man page should
> Am 2016-05-10 14:41, schrieb Vincent Lefevre:
> > On 2016-05-10 13:41:14 +0200, Christian Seiler wrote:
> > > Yes, so the problem is that gtk3-nocsd sets
> > > LD_PRELOAD=libgtk3-noscd.so.0.
> > > That means that ld.so tries to preload the library - and there's
> > > currently
> > > now way of telling ld.so to not print an error and simply ignore and
> > > entry
> > > in LD_PRELOAD if it can't load it. (And you only have the amd64
> > > version
> > > installed.)
> >
> > This would have been the best solution
>
> I agree. Maybe I should open a bug report against libc...
also be improved to know what happens in case of all kinds of errors.
> > Perhaps in the long term, ld.so should provide a way to avoid
> > error messages due to non-matching permissions or ELF class.
>
> Yes. And not only for permissions, I'd really like to have something like
> "please try this. If it doesn't work, don't worry, just continue, don't
> say anything".
ld.so, whatever the reason for which a clear decision can be made.
An error message + failure would be useful only in case of real error
(e.g. I/O error on some directory in the library search path).
> > Perhaps provide a 32-bit library for the amd64 package? But one should
> > still make sure that packages in both arch are coinstallable.
>
> I'm not a fan of special-casing amd64/i386 here, because on ARM you'll
> easily have the same issue (e.g. arm64 system with some 32bit armhf
> binaries) in principle. (Although I don't know if arm64 has multilib or
> only supports real multiarch.)
tedious). Unfortunately, this is not a perfect solution since
ARM doesn't seem to have multilib: the dependencies on
https://packages.debian.org/sid/gcc-5-multilib
can give an idea for the various architectures.
Christian Seiler
May 28, 2016, 9:30:06 AM5/28/16
to
On 05/10/2016 03:45 PM, Vincent Lefevre wrote:
> On 2016-05-10 15:12:43 +0200, Christian Seiler wrote:
>> Am 2016-05-10 14:41, schrieb Vincent Lefevre:
>>> On 2016-05-10 13:41:14 +0200, Christian Seiler wrote:
>>>> Yes, so the problem is that gtk3-nocsd sets
>>>> LD_PRELOAD=libgtk3-noscd.so.0.
>>>> That means that ld.so tries to preload the library - and there's
>>>> currently
>>>> now way of telling ld.so to not print an error and simply ignore and
>>>> entry
>>>> in LD_PRELOAD if it can't load it. (And you only have the amd64
>>>> version
>>>> installed.)
>>>
>>> This would have been the best solution
>>
>> I agree. Maybe I should open a bug report against libc...
>
> Yes.
I've now done so (including a patch):
> On 2016-05-10 15:12:43 +0200, Christian Seiler wrote:
>> Am 2016-05-10 14:41, schrieb Vincent Lefevre:
>>> On 2016-05-10 13:41:14 +0200, Christian Seiler wrote:
>>>> Yes, so the problem is that gtk3-nocsd sets
>>>> LD_PRELOAD=libgtk3-noscd.so.0.
>>>> That means that ld.so tries to preload the library - and there's
>>>> currently
>>>> now way of telling ld.so to not print an error and simply ignore and
>>>> entry
>>>> in LD_PRELOAD if it can't load it. (And you only have the amd64
>>>> version
>>>> installed.)
>>>
>>> This would have been the best solution
>>
>> I agree. Maybe I should open a bug report against libc...
>
> Yes.
https://sourceware.org/bugzilla/show_bug.cgi?id=20172
Regards,
Christian
0 new messages