Debian Bug report logs - #321718
Upgrade caused many libs to complain about "executable stack"

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Joe Mason <joe@notcharles.ca>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Upgrade caused many libs to complain about "executable stack"

Date: Sun, 07 Aug 2005 02:56:10 -0400

Package: upgrade-reports
Severity: critical

I just did a dist-upgrade, and every time I try to run a program linked
with libacl (which includes mv, cp, and ls) I get the following error:

error while loading shared libraries: libacl.so.1: cannot enable
executable stack as shared object requires: Error 14

This makes the entire system unusable.

I was able to get around it by downloading a statically linked busybox,
but there are many other libraries doing the same thing (so far I've
found libgcrypt, libcrypto, and libelf, and I'm filing bugs for all of
them).  Notably libgcrypt is used by whatever apt spawns to verify
package signatures, which means that I can't run an apt-get to
completion.

Google suggests this has something to do with "pax", which I've never 
heard of and have certainly never installed or enabled.


-- System Information:
Debian Release: testing/unstable
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.4.18-bf2.4
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Message #10 received at 321718@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Joe Mason <joe@notcharles.ca>, 321718@bugs.debian.org

Cc: debian-glibc@lists.debian.org

Subject: Re: Bug#321718: Upgrade caused many libs to complain about "executable stack"

Date: Sun, 7 Aug 2005 01:51:35 -0700

[Message part 1 (text/plain, inline)]

reassign 321717 glibc 2.3.5-1
reassign 321718 glibc 2.3.5-1
reassign 321720 glibc 2.3.5-1
reassign 321721 glibc 2.3.5-1
reassign 321723 glibc 2.3.5-1
reassign 321724 glibc 2.3.5-1
merge 321718 321717 321720 321721 321723 321724
severity 321718 important
thanks

On Sun, Aug 07, 2005 at 02:56:10AM -0400, Joe Mason wrote:
> (so far I've found libgcrypt, libcrypto, and libelf, and I'm filing bugs
> for all of them).

I'd rather you hadn't.  None of these libraries are buggy.  In the future,
it would be appreciated if you would open a single bug report describing
your issue, and let the developers sort out where the problem lies.

> Package: upgrade-reports
> Severity: critical

> I just did a dist-upgrade, and every time I try to run a program linked
> with libacl (which includes mv, cp, and ls) I get the following error:

> error while loading shared libraries: libacl.so.1: cannot enable
> executable stack as shared object requires: Error 14

> This makes the entire system unusable.

This error message originates with glibc, and appears to be new as of glibc
2.3.5.  Your reportbug-generated dependency lists confirm that this is the
version you're running.  So this bug, such as it is, belongs to the glibc
package; I've reassigned accordingly.

However, it's also apparent from the system details in your report that your
system is in an unsupported state:

> Google suggests this has something to do with "pax", which I've never 
> heard of and have certainly never installed or enabled.

> -- System Information:
> Debian Release: testing/unstable
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: i386 (i686)
> Shell:  /bin/sh linked to /bin/bash
> Kernel: Linux 2.4.18-bf2.4
> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Setting aside the oddity of your apt configuration here, it's evident that
you've tried to upgrade your system to current Debian unstable while running
a kernel from *woody*.  It is the policy of the Debian release team that
direct upgrades from woody to etch will not be supported, and this is an
interesting example of why that policy is warranted.  There have been no
other reports of this problem even though glibc 2.3.5 has been in
preparation for some time, and I have at least one system that is running
glibc 2.3.5 successfully with a 2.4.27 kernel from sarge, so apparently this
is an incompatibility that only exists between pre-sarge kernels and glibc
2.3.5.

It should be straightforward for you to fix your system by installing a
2.4.27 kernel from sarge and rebooting the machine, which is the supported
upgrade path in any case.  This means the bug should not be considered
critical; I've downgraded it accordingly.

It is still important that the glibc package be fixed, so that it does not
permit installation on an unsupported kernel.  This has been done in the
past for select architectures, but it seems we now have a reason to bump the
requirement across all architectures, which should give the glibc team a
nice clean start (and a nice clean preinst) for etch. :)

Thanks,
-- 
Steve Langasek
postmodern programmer

[signature.asc (application/pgp-signature, inline)]

Message #21 received at 321718@bugs.debian.org (full text, mbox, reply):

From: Jerzy Kozera <jerzy.kozera@gmail.com>

To: 321718@bugs.debian.org, Steve Langasek <vorlon@debian.org>

Cc: debian-glibc@lists.debian.org

Subject: Re: Bug#321718: Upgrade caused many libs to complain about "executable stack"

Date: Sun, 07 Aug 2005 11:28:41 +0200

On Sun, 2005-08-07 at 01:51 -0700, Steve Langasek wrote:
> > Google suggests this has something to do with "pax", which I've never 
> > heard of and have certainly never installed or enabled.
> 
> > -- System Information:
> > Debian Release: testing/unstable
> >   APT prefers stable
> >   APT policy: (500, 'stable')
> > Architecture: i386 (i686)
> > Shell:  /bin/sh linked to /bin/bash
> > Kernel: Linux 2.4.18-bf2.4
> > Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

[...]

> It should be straightforward for you to fix your system by installing a
> 2.4.27 kernel from sarge and rebooting the machine, which is the supported
> upgrade path in any case.  This means the bug should not be considered
> critical; I've downgraded it accordingly.
> 
> It is still important that the glibc package be fixed, so that it does not
> permit installation on an unsupported kernel.  This has been done in the
> past for select architectures, but it seems we now have a reason to bump the
> requirement across all architectures, which should give the glibc team a
> nice clean start (and a nice clean preinst) for etch. :)

This bug appears with my 2.6.x grsecurity/PaX kernel too. I'm getting
similiar error with:
$ wget
wget: error while loading shared libraries: libcrypto.so.0.9.7: cannot
enable executable stack as shared object requires: Permission denied

It goes away after turning off mprotect() protection by chpax or
downgrading libc6 back to 2.3.2-ds1-22.

You might be interested in related threads at
- debian-user: http://lists.debian.org/debian-user/2005/08/msg00747.html
- grsecurity forums: http://forums.grsecurity.net/viewtopic.php?t=1152

Will it be fixed so that libc will work with grsecurity/PaX?

Message #26 received at 321718@bugs.debian.org (full text, mbox, reply):

From: Joe Mason <joe@notcharles.ca>

To: Steve Langasek <vorlon@debian.org>

Cc: Joe Mason <joe@notcharles.ca>, 321718@bugs.debian.org, debian-glibc@lists.debian.org

Subject: Re: Bug#321718: Upgrade caused many libs to complain about "executable stack"

Date: Sun, 07 Aug 2005 05:10:49 -0400

On Sun, Aug 07, 2005 at 01:51:35AM -0700, Steve Langasek wrote:
> reassign 321717 glibc 2.3.5-1
> reassign 321718 glibc 2.3.5-1
> reassign 321720 glibc 2.3.5-1
> reassign 321721 glibc 2.3.5-1
> reassign 321723 glibc 2.3.5-1
> reassign 321724 glibc 2.3.5-1
> merge 321718 321717 321720 321721 321723 321724
> severity 321718 important
> thanks
> 
> On Sun, Aug 07, 2005 at 02:56:10AM -0400, Joe Mason wrote:
> > (so far I've found libgcrypt, libcrypto, and libelf, and I'm filing bugs
> > for all of them).
> 
> I'd rather you hadn't.  None of these libraries are buggy.  In the future,
> it would be appreciated if you would open a single bug report describing
> your issue, and let the developers sort out where the problem lies.

Sorry - I was rather annoyed because I logged on to IRC, and halfway
through explaining what I'd found out on Google about the problem and
why I had no idea where to look next, somebody cut me off and says,
"Just google for the answer, fix it, and then log the solution in the
BTS!"  And everyone else ignored me.  So I figured if I was being told
rudely to use the BTS, I should file some bugs, and I had no idea which
package was the root cause.  I didn't notice the catch-all "upgrade
problems" package until I'd already filed some other ones.

> > Package: upgrade-reports
> > Severity: critical
> 
> > I just did a dist-upgrade, and every time I try to run a program linked
> > with libacl (which includes mv, cp, and ls) I get the following error:
> 
> > error while loading shared libraries: libacl.so.1: cannot enable
> > executable stack as shared object requires: Error 14
> 
> > This makes the entire system unusable.
> 
> This error message originates with glibc, and appears to be new as of glibc
> 2.3.5.  Your reportbug-generated dependency lists confirm that this is the
> version you're running.  So this bug, such as it is, belongs to the glibc
> package; I've reassigned accordingly.

I downgraded to glibc from testing.  Here are some more details - I'm
not sure how to attach it to the glibc bug.

I was able to build "execstack" statically on another machine.  Running
"execstack -c" on most of the libs giving the error made it go away, but
not for libcrypto.so.  I assume libcrypto actually does require an
executable stack, unlike the others who were just accidentally marked
that way.

When I downgraded glibc, I noticed it uninstalling a package called
"libselinux1" - that looks very suspicious, but I don't know if it was
installed during the upgrade or if I installed it a while ago and forgot
about it.  I could have sworn I hadn't been playing around with any
security patches on this machine, but I guess if I had been that could
have caused the problem.

> However, it's also apparent from the system details in your report that your
> system is in an unsupported state:
> 
> > Google suggests this has something to do with "pax", which I've never 
> > heard of and have certainly never installed or enabled.
> 
> > -- System Information:
> > Debian Release: testing/unstable
> >   APT prefers stable
> >   APT policy: (500, 'stable')
> > Architecture: i386 (i686)
> > Shell:  /bin/sh linked to /bin/bash
> > Kernel: Linux 2.4.18-bf2.4
> > Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
> 
> Setting aside the oddity of your apt configuration here, it's evident that

The apt configuration is because I was running apt-cacher (pointed at
localhost).  One of the first things that broke was apache, which
apt-cacher depends on, so that I had to overwrite my sources.list with a
more standard one to get apt working again.  When I did that, I
accidentally put "stable" instead of "unstable".  I had actually been
running unstable for months, but hadn't done a dist-upgrade for a long
time.

So:
1. install unstable
2. months later, dist-upgrade (which fails to finish)
3. overwrite sources.list with one pointing to stable
4. apt-get update

I think that's why it was listed as "prefers stable" at that point.

> you've tried to upgrade your system to current Debian unstable while running
> a kernel from *woody*.  It is the policy of the Debian release team that
> direct upgrades from woody to etch will not be supported, and this is an
> interesting example of why that policy is warranted.  There have been no
> other reports of this problem even though glibc 2.3.5 has been in
> preparation for some time, and I have at least one system that is running
> glibc 2.3.5 successfully with a 2.4.27 kernel from sarge, so apparently this
> is an incompatibility that only exists between pre-sarge kernels and glibc
> 2.3.5.

As I said, I've been running sarge for quite some time, but I hadn't
upgraded my kernel for ages.  I try to avoid touching the kernel as long
as it's working - I'd assumed dist-upgrade would notice if the kernel
needed to be upgraded, and warn me.

> It is still important that the glibc package be fixed, so that it does not
> permit installation on an unsupported kernel.  This has been done in the

Oops, I guess that'd be the warning I was expecting.

Thanks for the prompt reply.
Joe

Message #31 received at 321718@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Jerzy Kozera <jerzy.kozera@gmail.com>

Cc: 321718@bugs.debian.org, 321718-submitter@bugs.debian.org, libelf@packages.debian.org, gdbm@packages.debian.org

Subject: Re: Bug#321718: Upgrade caused many libs to complain about "executable stack"

Date: Sun, 7 Aug 2005 03:51:43 -0700

[Message part 1 (text/plain, inline)]

unmerge 321724
reassign 321724 libelfg0 0.8.5-1
unmerge 321723
reassign 321723 libgdbm3 1.8.3-2
unmerge 321721
reassign 321721 libssl0.9.7 0.9.7e-3
severity 321721 minor
unmerge 321720
reassign 321720 libgcrypt11 1.2.0-11.1
severity 321720 minor
thanks

On Sun, Aug 07, 2005 at 11:28:41AM +0200, Jerzy Kozera wrote:
> On Sun, 2005-08-07 at 01:51 -0700, Steve Langasek wrote:
> > > Google suggests this has something to do with "pax", which I've never 
> > > heard of and have certainly never installed or enabled.

> > > -- System Information:
> > > Debian Release: testing/unstable
> > >   APT prefers stable
> > >   APT policy: (500, 'stable')
> > > Architecture: i386 (i686)
> > > Shell:  /bin/sh linked to /bin/bash
> > > Kernel: Linux 2.4.18-bf2.4
> > > Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

> [...]

> > It should be straightforward for you to fix your system by installing a
> > 2.4.27 kernel from sarge and rebooting the machine, which is the supported
> > upgrade path in any case.  This means the bug should not be considered
> > critical; I've downgraded it accordingly.

> > It is still important that the glibc package be fixed, so that it does not
> > permit installation on an unsupported kernel.  This has been done in the
> > past for select architectures, but it seems we now have a reason to bump the
> > requirement across all architectures, which should give the glibc team a
> > nice clean start (and a nice clean preinst) for etch. :)

> This bug appears with my 2.6.x grsecurity/PaX kernel too. I'm getting
> similiar error with:
> $ wget
> wget: error while loading shared libraries: libcrypto.so.0.9.7: cannot
> enable executable stack as shared object requires: Permission denied

> It goes away after turning off mprotect() protection by chpax or
> downgrading libc6 back to 2.3.2-ds1-22.

> You might be interested in related threads at
> - debian-user: http://lists.debian.org/debian-user/2005/08/msg00747.html
> - grsecurity forums: http://forums.grsecurity.net/viewtopic.php?t=1152

> Will it be fixed so that libc will work with grsecurity/PaX?

Ok, after talking with Bastian Blank on IRC, it looks fairly implausible
that the version information provided in the original reports was at all
correct.  For one thing, the version of libacl1 that bug #321717 was
reported against was a binNMU version of the package which I uploaded to fix
exactly this issue in bug #301250!

So, even though running etch/sid against a woody kernel is indeed not
supported, that doesn't seem the issue here.

Instead, Joe, it looks like you *are* running a kernel on this machine that
has grsec enabled, even if you don't know how it got there.  It would be
helpful to have more complete information from the actual system in question
to confirm this, though.

I can confirm that the binaries of libacl1 and libelfg0 that shipped in
sarge were built with an old compiler that did not properly set
PT_GNU_STACK.  The libacl1 bug was fixed in the binNMU mentioned.  The bug
in libelfg0 has not been fixed; I've unmerged 321724 and reassigned it back
to libelfg0.  Alex, this should be fixable with a simple rebuild of the
package.

I cannot directly confirm which compiler version was used for building gdbm,
but this package was last rebuilt in September 2003, and the binary is
missing a PT_GNU_STACK header, so there is a reasonable chance it was built
with gcc-2.95.  The libgdbm3 package has the same version in sarge and in
sid; James, it looks like we may want to try rebuilding gdbm to see if it
fixes this problem.  Reassigned back to libgdbm3.

Both the sarge and the sid versions of libssl0.9.7 were definitely *not*
built with gcc-2.95, but they both have a PT_GNU_STACK header in
/usr/lib/i686/cmov/libcrypto.so.0.9.7 which explicitly requests an
executable stack.  This is not the same bug as the others, which were
getting an executable stack by default.  Since there may be legitimate
reasons for requesting an executable stack, I'm downgrading this bug to
minor in addition to reassigning it -- anyone playing with grsec/PaX should
be prepared for the possibility of having to deal with setting such policies
on binaries where needed.

The bug against libgcrypt11 is the same as that against libssl0.9.7 -- the
library has explicitly requested an executable stack.  I don't think this is
a coincidence: it's pretty likely that both of these libraries *use* the
executable stack, which means there's not much chance of them being fixed. 
Reassigning and downgrading, in any case.

The last bug, I'm leaving assigned to glibc, since that is the package whose
behavior change triggered these reports.  Of course, this is simply a case
of glibc bailing on error from mprotect() rather than silently ignoring the
permission issues, so I imagine the glibc maintainers won't do anything with
this bug except close it...

In any case, none of these bugs are of severity higher than important.
There is no policy that Debian supports grsec kernels, and this narrow use
case does not otherwise meet the definition of a "grave" or "critical" bug.

Thanks,
-- 
Steve Langasek
postmodern programmer

[signature.asc (application/pgp-signature, inline)]

Message #47 received at 321718@bugs.debian.org (full text, mbox, reply):

From: Joe Mason <joe@notcharles.ca>

To: Steve Langasek <vorlon@debian.org>, 321718-quiet@bugs.debian.org

Cc: Jerzy Kozera <jerzy.kozera@gmail.com>, 321718@bugs.debian.org, 321718-submitter@bugs.debian.org, libelf@packages.debian.org, gdbm@packages.debian.org

Subject: Re: Bug#321718: Upgrade caused many libs to complain about "executable stack"

Date: Sun, 07 Aug 2005 17:42:03 -0400

[Message part 1 (text/plain, inline)]

On Sun, Aug 07, 2005 at 03:51:43AM -0700, Steve Langasek wrote:
> Ok, after talking with Bastian Blank on IRC, it looks fairly implausible
> that the version information provided in the original reports was at all
> correct.  For one thing, the version of libacl1 that bug #321717 was
> reported against was a binNMU version of the package which I uploaded to fix
> exactly this issue in bug #301250!

Yes, I tried upgrading and downgrading libacl a few times to see if it
fixed it before reporting the bug, and it's possible that it went away
and I didn't notice, as I was simultaneously dealing with all the other
libs.

> So, even though running etch/sid against a woody kernel is indeed not
> supported, that doesn't seem the issue here.
> 
> Instead, Joe, it looks like you *are* running a kernel on this machine that
> has grsec enabled, even if you don't know how it got there.  It would be
> helpful to have more complete information from the actual system in question
> to confirm this, though.

jnc@gate:/boot$ uname -a
Linux gate 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 GNU/Linux
jnc@gate:/boot$ dpkg -l|grep kern
ii  iptables                1.3.3-1                  Linux kernel 2.4+
iptables administration to
ii  linux-kernel-headers    2.6.13+0rc3-1            Linux Kernel
Headers for development
rc  nfs-kernel-server       1.0-2woody3              Kernel NFS server
support
jnc@gate:/boot$ ls /boot
System.map-2.4.18-bf2.4  coffee.bmp           debianlilo.bmp  sid.bmp
boot.0300                config-2.4.18-bf2.4  map
vmlinuz-2.4.18-bf2.4
boot.b                   debian.bmp           sarge.bmp

I can confirm vmlinuz-2.4.18-bf2.4 is the kernel being booted.

The System.map and config files are attached.

This kernel was compiled on another machine and installed by hand
instead of going through kpkg.  Unfortunately I don't have the sources
anymore, but I don't recall installing any patches, which I understand
would be necessary for "grsecurity".  I did spend a while playing with
various kernel patches on another machine, so it's possible I'm mixed up
and installed that kernel here, but I'd figured out kpkg by that time so
I probably would have a kernel package if I'd done that.

As I mentioned in another mail, I found a "libselinux1" installed as I
was downgrading libc, and I don't know if it was installed new during
the dist-upgrade or had been sitting on the machine for a while.
Downgrading libc required libselinux1 to be uninstalled, so it was at
least upgraded during the dist-upgrade.  I suppose it's possible I was
playing with SELinux and totally forgot, but I'm sure I would have used
a different machine for that.

> Both the sarge and the sid versions of libssl0.9.7 were definitely *not*
> built with gcc-2.95, but they both have a PT_GNU_STACK header in
> /usr/lib/i686/cmov/libcrypto.so.0.9.7 which explicitly requests an
> executable stack.  This is not the same bug as the others, which were
> getting an executable stack by default.  Since there may be legitimate
> reasons for requesting an executable stack, I'm downgrading this bug to
> minor in addition to reassigning it -- anyone playing with grsec/PaX should
> be prepared for the possibility of having to deal with setting such policies
> on binaries where needed.
> 
> The bug against libgcrypt11 is the same as that against libssl0.9.7 -- the
> library has explicitly requested an executable stack.  I don't think this is
> a coincidence: it's pretty likely that both of these libraries *use* the
> executable stack, which means there's not much chance of them being fixed. 
> Reassigning and downgrading, in any case.

I can confirm this, as "execstack -c" caused the error to disappear for
the other libraries but not libcrypto.  The problem remains that if they
need an executable stack they should be able to get it, so in this case
I'd say the problem is with the kernel.

> The last bug, I'm leaving assigned to glibc, since that is the package whose
> behavior change triggered these reports.  Of course, this is simply a case
> of glibc bailing on error from mprotect() rather than silently ignoring the
> permission issues, so I imagine the glibc maintainers won't do anything with
> this bug except close it...

Aha, so my kernel has been "broken" for ages but libc was ignoring it.
Wonderful.  I'll install a new one tomorrow, and back up my /boot
directory in case anyone needs to take a look at the current one.

Joe

[System.map-2.4.18-bf2.4 (text/plain, attachment)]

[config-2.4.18-bf2.4 (text/plain, attachment)]

Message #60 received at 321718@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Joe Mason <joe@notcharles.ca>

Cc: 321718@bugs.debian.org

Subject: Re: Bug#321718: Upgrade caused many libs to complain about "executable stack"

Date: Mon, 8 Aug 2005 06:38:24 -0700

[Message part 1 (text/plain, inline)]

On Sun, Aug 07, 2005 at 05:42:03PM -0400, Joe Mason wrote:
> > So, even though running etch/sid against a woody kernel is indeed not
> > supported, that doesn't seem the issue here.

> > Instead, Joe, it looks like you *are* running a kernel on this machine that
> > has grsec enabled, even if you don't know how it got there.  It would be
> > helpful to have more complete information from the actual system in question
> > to confirm this, though.

> jnc@gate:/boot$ uname -a
> Linux gate 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 GNU/Linux
> jnc@gate:/boot$ dpkg -l|grep kern
> ii  iptables                1.3.3-1                  Linux kernel 2.4+
> iptables administration to
> ii  linux-kernel-headers    2.6.13+0rc3-1            Linux Kernel
> Headers for development
> rc  nfs-kernel-server       1.0-2woody3              Kernel NFS server
> support
> jnc@gate:/boot$ ls /boot
> System.map-2.4.18-bf2.4  coffee.bmp           debianlilo.bmp  sid.bmp
> boot.0300                config-2.4.18-bf2.4  map
> vmlinuz-2.4.18-bf2.4
> boot.b                   debian.bmp           sarge.bmp

> I can confirm vmlinuz-2.4.18-bf2.4 is the kernel being booted.

Ok, that brings us back to the point of the current glibc needing to raise
its minimum version number for kernel compatibility.

> This kernel was compiled on another machine and installed by hand
> instead of going through kpkg.  Unfortunately I don't have the sources
> anymore, but I don't recall installing any patches, which I understand
> would be necessary for "grsecurity".  I did spend a while playing with
> various kernel patches on another machine, so it's possible I'm mixed up
> and installed that kernel here, but I'd figured out kpkg by that time so
> I probably would have a kernel package if I'd done that.

Sure.  It seems there's been another report of this problem with a 2.4.18
kernel, and I guess the origin of the incompatibility has also been
identified:

08:47 <waldi> mprotect(0xbffff000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = -1 EINVAL (Invalid argument)
08:47 <waldi> mprotect(0xbfff8000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EFAULT (Bad address)
08:55 <waldi> PROT_GROWSDOWN seems to be new in 2.4.21 and 2.5

I'm not sure there were ever grsec packages available for 2.4.18 anyway, but
it seems irrelevant after all.

> > The last bug, I'm leaving assigned to glibc, since that is the package whose
> > behavior change triggered these reports.  Of course, this is simply a case
> > of glibc bailing on error from mprotect() rather than silently ignoring the
> > permission issues, so I imagine the glibc maintainers won't do anything with
> > this bug except close it...

> Aha, so my kernel has been "broken" for ages but libc was ignoring it.
> Wonderful.  I'll install a new one tomorrow, and back up my /boot
> directory in case anyone needs to take a look at the current one.

Ok.  I think this bug should be trackable from here without recourse to your
/boot, but please report back if for some reason upgrading the kernel
doesn't fix the problem for you.

Cheers,
-- 
Steve Langasek
postmodern programmer

[signature.asc (application/pgp-signature, inline)]

Message #65 received at 321718@bugs.debian.org (full text, mbox, reply):

From: Daniel Jacobowitz <drow@false.org>

To: Steve Langasek <vorlon@debian.org>, 321718@bugs.debian.org

Cc: Joe Mason <joe@notcharles.ca>

Subject: Re: Bug#321718: Upgrade caused many libs to complain about "executable stack"

Date: Mon, 8 Aug 2005 10:09:38 -0400

On Mon, Aug 08, 2005 at 06:38:24AM -0700, Steve Langasek wrote:
> > This kernel was compiled on another machine and installed by hand
> > instead of going through kpkg.  Unfortunately I don't have the sources
> > anymore, but I don't recall installing any patches, which I understand
> > would be necessary for "grsecurity".  I did spend a while playing with
> > various kernel patches on another machine, so it's possible I'm mixed up
> > and installed that kernel here, but I'd figured out kpkg by that time so
> > I probably would have a kernel package if I'd done that.
> 
> Sure.  It seems there's been another report of this problem with a 2.4.18
> kernel, and I guess the origin of the incompatibility has also been
> identified:
> 
> 08:47 <waldi> mprotect(0xbffff000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = -1 EINVAL (Invalid argument)
> 08:47 <waldi> mprotect(0xbfff8000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EFAULT (Bad address)
> 08:55 <waldi> PROT_GROWSDOWN seems to be new in 2.4.21 and 2.5

I have no idea why waldi thinks PROT_GROWSDOWN is the problem.  Rather,
the EFAULT is the problem.  At a guess, this is the case that we expect
ENOMEM for in dl-execstack.c, but 2.4.18 is returning EFAULT instead
for the same case.

This whole thing looks a bit fishy, since it could be making random
other bits writable... but that won't happen in recent kernels, anyway.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Message #70 received at 321718@bugs.debian.org (full text, mbox, reply):

From: Marc-Christian Petersen <m.c.p@linux-systeme.com>

To: Debian Bug Tracking System <321718@bugs.debian.org>

Subject: glibc: Upgrade caused many libs to complain about "executable stack"

Date: Mon, 08 Aug 2005 16:25:32 +0200

Package: glibc
Followup-For: Bug #321718

Hi all,

I'd suggest to rebuild all required packages (libraries) with
CFLAGS -Wa,--noexecstack so that assembled modules get tagged
as not needing executable stacks.

I've rebuilt some packages (liblzo1, openssl, libgdbm3, libelfg0,
libgcrypt11 and so on) with those flags. For everyone who's
interested: http://debian.linux-systeme.com/

Not an option (imho) is to disable mprotect() with chpax(8) or
paxctl(1) on binaries complaining about permission denied of
executable stack.

Kind regards,
	Marc

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.4.20-wolk4.18s
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Message #75 received at 321718@bugs.debian.org (full text, mbox, reply):

From: Daniel Jacobowitz <drow@false.org>

To: Marc-Christian Petersen <m.c.p@linux-systeme.com>, 321718@bugs.debian.org

Subject: Re: Bug#321718: glibc: Upgrade caused many libs to complain about "executable stack"

Date: Mon, 8 Aug 2005 10:52:01 -0400

On Mon, Aug 08, 2005 at 04:25:32PM +0200, Marc-Christian Petersen wrote:
> Package: glibc
> Followup-For: Bug #321718
> 
> Hi all,
> 
> I'd suggest to rebuild all required packages (libraries) with
> CFLAGS -Wa,--noexecstack so that assembled modules get tagged
> as not needing executable stacks.
> 
> I've rebuilt some packages (liblzo1, openssl, libgdbm3, libelfg0,
> libgcrypt11 and so on) with those flags. For everyone who's
> interested: http://debian.linux-systeme.com/

Absolutely not.  Either the package needs an executable stack - in
which case this is, simply, wrong - or else it doesn't and whatever is
causing it to be tagged as needing one should be fixed.  IIRC it is
usually a matter of annotating assembly files in some way.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Message #80 received at 321718@bugs.debian.org (full text, mbox, reply):

From: Marc-Christian Petersen <m.c.p@linux-systeme.com>

To: Daniel Jacobowitz <drow@false.org>

Cc: 321718@bugs.debian.org

Subject: Re: Bug#321718: glibc: Upgrade caused many libs to complain about "executable stack"

Date: Thu, 11 Aug 2005 15:32:18 +0200

On Monday 08 August 2005 16:52, Daniel Jacobowitz wrote:

> > I'd suggest to rebuild all required packages (libraries) with
> > CFLAGS -Wa,--noexecstack so that assembled modules get tagged
> > as not needing executable stacks.
> >
> > I've rebuilt some packages (liblzo1, openssl, libgdbm3, libelfg0,
> > libgcrypt11 and so on) with those flags. For everyone who's
> > interested: http://debian.linux-systeme.com/
>
> Absolutely not.  Either the package needs an executable stack - in
> which case this is, simply, wrong - or else it doesn't and whatever is
> causing it to be tagged as needing one should be fixed.  IIRC it is
> usually a matter of annotating assembly files in some way.

well, so I've uploaded a glibc 2.3.5 package with PaX support.

ciao, Marc

Message #85 received at 321718@bugs.debian.org (full text, mbox, reply):

From: GOTO Masanori <gotom@debian.or.jp>

To: Daniel Jacobowitz <drow@false.org>, 321718@bugs.debian.org

Cc: Steve Langasek <vorlon@debian.org>, Joe Mason <joe@notcharles.ca>

Subject: Re: Bug#321718: Upgrade caused many libs to complain about "executable stack"

Date: Mon, 15 Aug 2005 13:48:36 +0900

At Mon, 8 Aug 2005 10:09:38 -0400,
Daniel Jacobowitz wrote:
> > 08:47 <waldi> mprotect(0xbffff000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = -1 EINVAL (Invalid argument)
> > 08:47 <waldi> mprotect(0xbfff8000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EFAULT (Bad address)
> > 08:55 <waldi> PROT_GROWSDOWN seems to be new in 2.4.21 and 2.5
> 
> I have no idea why waldi thinks PROT_GROWSDOWN is the problem.  Rather,
> the EFAULT is the problem.  At a guess, this is the case that we expect
> ENOMEM for in dl-execstack.c, but 2.4.18 is returning EFAULT instead
> for the same case.

I don't know what the exact problem is - Does this problem occur with
2.4 kernel?  Can all furious PaX reports be fixed using 2.6 kernel?

Regards,
-- gotom

Message #90 received at 321718@bugs.debian.org (full text, mbox, reply):

From: Daniel Jacobowitz <drow@false.org>

To: GOTO Masanori <gotom@debian.or.jp>

Cc: 321718@bugs.debian.org, Steve Langasek <vorlon@debian.org>, Joe Mason <joe@notcharles.ca>

Subject: Re: Bug#321718: Upgrade caused many libs to complain about "executable stack"

Date: Mon, 15 Aug 2005 10:12:31 -0400

On Mon, Aug 15, 2005 at 01:48:36PM +0900, GOTO Masanori wrote:
> At Mon, 8 Aug 2005 10:09:38 -0400,
> Daniel Jacobowitz wrote:
> > > 08:47 <waldi> mprotect(0xbffff000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = -1 EINVAL (Invalid argument)
> > > 08:47 <waldi> mprotect(0xbfff8000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EFAULT (Bad address)
> > > 08:55 <waldi> PROT_GROWSDOWN seems to be new in 2.4.21 and 2.5
> > 
> > I have no idea why waldi thinks PROT_GROWSDOWN is the problem.  Rather,
> > the EFAULT is the problem.  At a guess, this is the case that we expect
> > ENOMEM for in dl-execstack.c, but 2.4.18 is returning EFAULT instead
> > for the same case.
> 
> I don't know what the exact problem is - Does this problem occur with
> 2.4 kernel?  Can all furious PaX reports be fixed using 2.6 kernel?

This is separate from the PaX problems - it's stock 2.4.  I don't know
why it happens, but someone would need to set up a 2.4 system to debug
it on.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Message #99 received at 321718@bugs.debian.org (full text, mbox, reply):

From: GOTO Masanori <gotom@debian.or.jp>

To: Daniel Jacobowitz <drow@false.org>, 321718@bugs.debian.org

Cc: GOTO Masanori <gotom@debian.or.jp>, Steve Langasek <vorlon@debian.org>, Joe Mason <joe@notcharles.ca>

Subject: Re: Bug#321718: Upgrade caused many libs to complain about "executable stack"

Date: Thu, 18 Aug 2005 20:59:17 +0900

At Mon, 15 Aug 2005 10:12:31 -0400,
Daniel Jacobowitz wrote:
> > I don't know what the exact problem is - Does this problem occur with
> > 2.4 kernel?  Can all furious PaX reports be fixed using 2.6 kernel?
> 
> This is separate from the PaX problems - it's stock 2.4.  I don't know
> why it happens, but someone would need to set up a 2.4 system to debug
> it on.

Thanks, I confirmed the problem.

When I booted up with 2.4.18-bf2.4, then I invoked "ssh",
libcrypto.so.0.9.7 got Error 14.  But kernel 2.4.26-1-686 does not
break.  As you already stated, this is because 2.4.18-bf2.4 returns
EFAULT instead of ENOMEM when the second of problematic mprotect() is
called during resolving libcrypto.so [1].  Then I looked at
/proc/pid/maps.  It says even on 2.4.18-bf2.4 [2]:

	bffff000-c0000000 rwxp 00000000 00:00 0

So the problem is the return value of mprotect is changed during
2.4.18 and 2.4.26.  I found some mail of this modifications:

	http://www.linux-mips.org/archives/linux-mips/2002-06/msg00215.html

	--- mm/mprotect.c       4 Mar 2002 11:13:35 -0000       1.1.1.1
	+++ mm/mprotect.c       25 Jun 2002 07:00:55 -0000
	@@ -284,7 +284,7 @@
	        down_write(&current->mm->mmap_sem);
	 
	        vma = find_vma_prev(current->mm, start, &prev);
	-       error = -EFAULT;
	+       error = -ENOMEM;
	        if (!vma || vma->vm_start > start)
	                goto out;
	 
	@@ -317,7 +317,7 @@
	                nstart = tmp;
	                vma = next;
	                if (!vma || vma->vm_start != nstart) {
	-                       error = -EFAULT;
	+                       error = -ENOMEM;
	                        goto out;
	                }
	        }

I found 2.6 kernel changelog said (Hi Adrian!):

    <akpm@osdl.org>
	[PATCH] mprotect return value fix
	From: Marc-Christian Petersen <m.c.p@wolk-project.de>
	2.4 patch from Adrian Bunk.
	ERRORS
	    The mprotect() function shall fail if:
	    ...
	    [ENOMEM]
	        Addresses in the range [addr,addr+len) are invalid for the
	        address space of a process, or specify one or more pages which are
	        not mapped.

This modification was done because mprotect returned EFAULT instead of
ENOMEM, that was simply POSIX violation.  The actual problem is linux
kernel 2.4.  But in order to work glibc 2.3.5 on etch, we need to fix
adhoc patch to change dl-execstack.c.  I don't know it's acceptable
for upstream, but it's worth fixing.  If it'll be rejected, this patch
should be marked as "until-etch" if etch does not support any 2.4
kernel hopefully.  Now the patch that I have not tested yet.  Is this
solution desired for the next 2.3.5-4?

	--- sysdeps/unix/sysv/linux/dl-execstack.c.gotom	2005-08-18 20:55:21.448088096 +0900
	+++ sysdeps/unix/sysv/linux/dl-execstack.c	2005-08-18 20:57:02.500725760 +0900
	@@ -84,7 +84,7 @@
	 	page -= size;
	       else
	 	{
	-	  if (errno != ENOMEM)	/* Unexpected failure mode.  */
	+	  if (errno != (ENOMEM | EFAULT))	/* Unexpected failure mode.  */
	 	    return errno;
	 
	 	  if (size == GLRO(dl_pagesize))
	@@ -107,7 +107,7 @@
	 	page += size;
	       else
	 	{
	-	  if (errno != ENOMEM)	/* Unexpected failure mode.  */
	+	  if (errno != (ENOMEM | EFAULT))	/* Unexpected failure mode.  */
	 	    return errno;
	 
	 	  if (size == GLRO(dl_pagesize))

BTW, I found the similar problem (which I checked for 2.4.19):

	http://lists.debian.org/debian-glibc/2003/02/msg00353.html

Regards,
-- gotom

[1]
2.4.18:
  mprotect(0xbffff000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = -1 EINVAL (Invalid argument)
  mprotect(0xbfff8000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EFAULT (Bad address)
2.4.26:
  mprotect(0xbffff000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = -1 EINVAL (Invalid argument)
  mprotect(0xbfff8000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 ENOMEM (Cannot allocate memory)
  mprotect(0xbfffc000, 16384, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 ENOMEM (Cannot allocate memory)
  mprotect(0xbfffe000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 ENOMEM (Cannot allocate memory)
  mprotect(0xbffff000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
  mprotect(0xbfffe000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 ENOMEM (Cannot allocate memory)
2.6.9:
  mprotect(0xbffff000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = 0

[2]
2.6 kernel: bffff000-c0000000 rwxp bffff000 00:00 0 

Message #104 received at 321718@bugs.debian.org (full text, mbox, reply):

From: Bastian Blank <waldi@debian.org>

To: GOTO Masanori <gotom@debian.or.jp>, 321718@bugs.debian.org

Cc: Daniel Jacobowitz <drow@false.org>, Steve Langasek <vorlon@debian.org>, Joe Mason <joe@notcharles.ca>

Subject: Re: Bug#321718: Upgrade caused many libs to complain about "executable stack"

Date: Thu, 18 Aug 2005 14:20:46 +0200

[Message part 1 (text/plain, inline)]

On Thu, Aug 18, 2005 at 08:59:17PM +0900, GOTO Masanori wrote:
> 	--- sysdeps/unix/sysv/linux/dl-execstack.c.gotom	2005-08-18 20:55:21.448088096 +0900
> 	+++ sysdeps/unix/sysv/linux/dl-execstack.c	2005-08-18 20:57:02.500725760 +0900
> 	@@ -84,7 +84,7 @@
> 	 	page -= size;
> 	       else
> 	 	{
> 	-	  if (errno != ENOMEM)	/* Unexpected failure mode.  */
> 	+	  if (errno != (ENOMEM | EFAULT))	/* Unexpected failure mode.  */
> 	 	    return errno;
> 	 
> 	 	  if (size == GLRO(dl_pagesize))
> 	@@ -107,7 +107,7 @@
> 	 	page += size;
> 	       else
> 	 	{
> 	-	  if (errno != ENOMEM)	/* Unexpected failure mode.  */
> 	+	  if (errno != (ENOMEM | EFAULT))	/* Unexpected failure mode.  */
> 	 	    return errno;
> 	 
> 	 	  if (size == GLRO(dl_pagesize))

errno != ENOMEN && errno != EFAULT

Bastian

-- 
Men of peace usually are [brave].
		-- Spock, "The Savage Curtain", stardate 5906.5

[signature.asc (application/pgp-signature, inline)]

Message #109 received at 321718@bugs.debian.org (full text, mbox, reply):

From: Christoph Hellwig <hch@lst.de>

To: GOTO Masanori <gotom@debian.or.jp>, 321718@bugs.debian.org

Cc: Daniel Jacobowitz <drow@false.org>, Steve Langasek <vorlon@debian.org>, Joe Mason <joe@notcharles.ca>

Subject: Re: Bug#321718: Upgrade caused many libs to complain about "executable stack"

Date: Thu, 18 Aug 2005 14:33:51 +0200

On Thu, Aug 18, 2005 at 08:59:17PM +0900, GOTO Masanori wrote:
> 	-	  if (errno != ENOMEM)	/* Unexpected failure mode.  */
> 	+	  if (errno != (ENOMEM | EFAULT))	/* Unexpected failure mode.  */

I don't think errno will ever have the value of (ENOMEM | EFAULT).
Should probably be

		if (errno != ENOMEM && errno != EFAULT)

Message #114 received at 321718@bugs.debian.org (full text, mbox, reply):

From: GOTO Masanori <gotom@debian.or.jp>

To: Christoph Hellwig <hch@lst.de>, Bastian Blank <waldi@debian.org>, 321718@bugs.debian.org

Cc: GOTO Masanori <gotom@debian.or.jp>, Daniel Jacobowitz <drow@false.org>, Steve Langasek <vorlon@debian.org>, Joe Mason <joe@notcharles.ca>

Subject: Re: Bug#321718: Upgrade caused many libs to complain about "executable stack"

Date: Thu, 18 Aug 2005 22:33:29 +0900

> 		if (errno != ENOMEM && errno != EFAULT)

Thanks, this is one of the best bug that I have produced, I go to
sleep now...

Regards,
-- gotom

Message #119 received at 321718@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: GOTO Masanori <gotom@debian.or.jp>

Cc: Daniel Jacobowitz <drow@false.org>, 321718@bugs.debian.org, Joe Mason <joe@notcharles.ca>

Subject: Re: Bug#321718: Upgrade caused many libs to complain about "executable stack"

Date: Thu, 18 Aug 2005 15:03:01 -0700

[Message part 1 (text/plain, inline)]

On Thu, Aug 18, 2005 at 08:59:17PM +0900, GOTO Masanori wrote:

> This modification was done because mprotect returned EFAULT instead of
> ENOMEM, that was simply POSIX violation.  The actual problem is linux
> kernel 2.4.  But in order to work glibc 2.3.5 on etch, we need to fix
> adhoc patch to change dl-execstack.c.  I don't know it's acceptable
> for upstream, but it's worth fixing.  If it'll be rejected, this patch
> should be marked as "until-etch" if etch does not support any 2.4
> kernel hopefully.  Now the patch that I have not tested yet.  Is this
> solution desired for the next 2.3.5-4?

Etch certainly won't support 2.4.18 officially; that will be an
oldstable-1 kernel at the time etch releases.  Is it really worth trying
to maintain compatibility with that kernel?

AIUI, glibc 2.3.5 is currently compatible with the sarge and etch 2.4
kernels.  That seems sufficient to me; why not just mark glibc in the
preinst as being incompatible with old 2.4 kernels?

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

[signature.asc (application/pgp-signature, inline)]

Message #124 received at 321717-close@bugs.debian.org (full text, mbox, reply):

From: GOTO Masanori <gotom@debian.org>

To: 321717-close@bugs.debian.org

Subject: Bug#321717: fixed in glibc 2.3.5-4

Date: Fri, 19 Aug 2005 06:17:17 -0700

Source: glibc
Source-Version: 2.3.5-4

We believe that the bug you reported is fixed in the latest version of
glibc, which is due to be installed in the Debian FTP archive:

glibc-doc_2.3.5-4_all.deb
  to pool/main/g/glibc/glibc-doc_2.3.5-4_all.deb
glibc_2.3.5-4.diff.gz
  to pool/main/g/glibc/glibc_2.3.5-4.diff.gz
glibc_2.3.5-4.dsc
  to pool/main/g/glibc/glibc_2.3.5-4.dsc
libc6-dbg_2.3.5-4_i386.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-4_i386.deb
libc6-dev_2.3.5-4_i386.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-4_i386.deb
libc6-i686_2.3.5-4_i386.deb
  to pool/main/g/glibc/libc6-i686_2.3.5-4_i386.deb
libc6-pic_2.3.5-4_i386.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-4_i386.deb
libc6-prof_2.3.5-4_i386.deb
  to pool/main/g/glibc/libc6-prof_2.3.5-4_i386.deb
libc6-udeb_2.3.5-4_i386.udeb
  to pool/main/g/glibc/libc6-udeb_2.3.5-4_i386.udeb
libc6_2.3.5-4_i386.deb
  to pool/main/g/glibc/libc6_2.3.5-4_i386.deb
libnss-dns-udeb_2.3.5-4_i386.udeb
  to pool/main/g/glibc/libnss-dns-udeb_2.3.5-4_i386.udeb
libnss-files-udeb_2.3.5-4_i386.udeb
  to pool/main/g/glibc/libnss-files-udeb_2.3.5-4_i386.udeb
locales_2.3.5-4_all.deb
  to pool/main/g/glibc/locales_2.3.5-4_all.deb
nscd_2.3.5-4_i386.deb
  to pool/main/g/glibc/nscd_2.3.5-4_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 321717@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
GOTO Masanori <gotom@debian.org> (supplier of updated glibc package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sat,  6 Aug 2005 06:52:42 +0900
Source: glibc
Binary: libc6-i686 libc6-dev-ppc64 libc0.3-pic glibc-doc libc1-udeb libc0.3 libc6.1-dev libc1-pic libc6-s390x libnss-files-udeb libc1-dbg libc6-dev-sparc64 libc0.3-dev libc6-udeb libc6-dbg libc6.1-pic libc6-dev libc0.3-prof libc6-sparcv9 libc6.1-prof libc1 locales libc6-pic libc0.3-udeb libc1-prof libc6-ppc64 libc0.3-dbg libc6-prof libc6 libc6-sparcv9b libc6.1-udeb libc6.1-dbg nscd libc6-sparc64 libnss-dns-udeb libc6.1 libc1-dev libc6-dev-s390x
Architecture: source i386 all
Version: 2.3.5-4
Distribution: unstable
Urgency: low
Maintainer: GOTO Masanori <gotom@debian.org>
Changed-By: GOTO Masanori <gotom@debian.org>
Description: 
 glibc-doc  - GNU C Library: Documentation
 libc6      - GNU C Library: Shared libraries and Timezone data
 libc6-dbg  - GNU C Library: Libraries with debugging symbols
 libc6-dev  - GNU C Library: Development Libraries and Header Files
 libc6-i686 - GNU C Library: Shared libraries [i686 optimized]
 libc6-pic  - GNU C Library: PIC archive library
 libc6-prof - GNU C Library: Profiling Libraries
 libc6-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libnss-dns-udeb - GNU C Library: NSS helper for DNS - udeb (udeb)
 libnss-files-udeb - GNU C Library: NSS helper for files - udeb (udeb)
 locales    - GNU C Library: National Language (locale) data [support]
 nscd       - GNU C Library: Name Service Cache Daemon
Closes: 321561 321712 321717 321718 321719 321740 321796 322506 322768 323352 323409 323487 323552 323560
Changes: 
 glibc (2.3.5-4) unstable; urgency=low
 .
   * The "hppa is important to someone, really - LaMont" release.
 .
   * GOTO Masanori <gotom@debian.org>
 .
     * d-i wants to remove libnss-files-udeb and libnss-dns-udeb dependency
       from libc-udeb.  Suggested by Joey Hess <joeyh@debian.org>.
       (Closes: #322506)
       - debian/control.in/libc: Remove libnss-files-udeb libnss-dns-udeb
         dependency.
       - debian/control: Update.
 .
     * Build-Depends fixes:
       - debian/control.in/main: Change gcc-* dependency from | to ,.
         Suggested by Andreas Jochens <aj@andaco.de>.
       - debian/control.in/main: Add gcc-4.0 (>= 4.0.1-5) [hppa], because prior
         versions cannot generate sane glibc binaries.
       - debian/control: Update.
 .
     * Enable libnss upgrade guard again.
       (Closes: #321561, #321712, #321796, #322768, #323560)
       - debian/debhelper.in/libc.preinst: Change guard to 2.3.5-1.
       - debian/debhelper.in/libc.postinst: Likewise.
       - debian/debhelper.in/libc.postinst: Fix to invoke NSS check again.
 .
     * debian/debhelper.in/nscd.dirs: Add /var/db/nscd.
       (Closes: #323352, #323487)
 .
     * debian/debhelper.in/locales.prerm: Add purge to remove locale-archive.
       (Closes: #321719)
 .
     * debian/patches/00list: Drop glibc234-hppa-remove-mallocdef.dpatch.
       It causes unconditional locking problem, because it was already replaced
       by Carlos' new patches.  Reported by LaMont Jones <lamont@debian.org>.
 .
     * Add Depends: lib64gcc1 and provide lib64c-dev for 64bit -dev packages.
       Suggested by Matthias Klose <doko@cs.tu-berlin.de>.  (Closes: #323552)
       - debian/control.in/sparc64: Likewise.
       - debian/control.in/ppc64: Likewise.
       - debian/control.in/s390x: Likewise.
       - debian/control: Update.
 .
     * debian/patches/glibc235-dl-execstack.dpatch: New file, to fix execstack
       failed to check on kernel <= 2.4.18.  (Closes: #321717, #321718, #323409)
 .
     * Roland Stigge <stigge@antcom.de>:
       - debian/debhelper.in/glibc-doc.install: Install HTML documents
         correctly.  (Closes: #321740)
Files: 
 b5f966da1bac2037f2c3250939665bf2 1733 libs required glibc_2.3.5-4.dsc
 cce2797679eb5a72552917205c58a8e2 294918 libs required glibc_2.3.5-4.diff.gz
 68c56229f8570af8f2f257cd3c2f3f2c 3330198 doc optional glibc-doc_2.3.5-4_all.deb
 37cb28ab4c4cfdd20ba8368f4fc98721 4057888 base standard locales_2.3.5-4_all.deb
 bb6dbd9475c74a4946092d32dcf9d148 4927430 base required libc6_2.3.5-4_i386.deb
 11c55fbdd91e3bb9bce31fa26f25dbea 2678864 libdevel standard libc6-dev_2.3.5-4_i386.deb
 79bbe3c04e2aa80abd32c23fa99aa053 1262672 libdevel extra libc6-prof_2.3.5-4_i386.deb
 7be8aef8e28c3ff7e6e8abcdbf6956ed 1010100 libdevel optional libc6-pic_2.3.5-4_i386.deb
 0448a23476d35e8d6b36d89648286b60 1006866 libs extra libc6-i686_2.3.5-4_i386.deb
 ff78ac9f175de45621c1fb49b734ca36 122578 admin optional nscd_2.3.5-4_i386.deb
 e7e7823b042a459c238a7bd4cbed6471 5945942 libdevel extra libc6-dbg_2.3.5-4_i386.deb
 2c946e6bf4c8f0d6d5f94da17597e30c 702862 debian-installer extra libc6-udeb_2.3.5-4_i386.udeb
 ccc70c566c634c19b44f53e309df03cd 8270 debian-installer extra libnss-dns-udeb_2.3.5-4_i386.udeb
 016ab73700c3956503915f65c7f06544 14856 debian-installer extra libnss-files-udeb_2.3.5-4_i386.udeb
package-type: udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDBdSoqIqasIZIJsMRAu/BAJ9JlI/xi3WXxvCOt9Ev7AqGTK9gbwCfSbz7
f6wWT3sxSMKyy/LsRc6s7cU=
=7XOJ
-----END PGP SIGNATURE-----

Message #129 received at 321718-close@bugs.debian.org (full text, mbox, reply):

From: GOTO Masanori <gotom@debian.org>

To: 321718-close@bugs.debian.org

Subject: Bug#321718: fixed in glibc 2.3.5-4

Date: Fri, 19 Aug 2005 06:17:17 -0700

Source: glibc
Source-Version: 2.3.5-4

We believe that the bug you reported is fixed in the latest version of
glibc, which is due to be installed in the Debian FTP archive:

glibc-doc_2.3.5-4_all.deb
  to pool/main/g/glibc/glibc-doc_2.3.5-4_all.deb
glibc_2.3.5-4.diff.gz
  to pool/main/g/glibc/glibc_2.3.5-4.diff.gz
glibc_2.3.5-4.dsc
  to pool/main/g/glibc/glibc_2.3.5-4.dsc
libc6-dbg_2.3.5-4_i386.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-4_i386.deb
libc6-dev_2.3.5-4_i386.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-4_i386.deb
libc6-i686_2.3.5-4_i386.deb
  to pool/main/g/glibc/libc6-i686_2.3.5-4_i386.deb
libc6-pic_2.3.5-4_i386.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-4_i386.deb
libc6-prof_2.3.5-4_i386.deb
  to pool/main/g/glibc/libc6-prof_2.3.5-4_i386.deb
libc6-udeb_2.3.5-4_i386.udeb
  to pool/main/g/glibc/libc6-udeb_2.3.5-4_i386.udeb
libc6_2.3.5-4_i386.deb
  to pool/main/g/glibc/libc6_2.3.5-4_i386.deb
libnss-dns-udeb_2.3.5-4_i386.udeb
  to pool/main/g/glibc/libnss-dns-udeb_2.3.5-4_i386.udeb
libnss-files-udeb_2.3.5-4_i386.udeb
  to pool/main/g/glibc/libnss-files-udeb_2.3.5-4_i386.udeb
locales_2.3.5-4_all.deb
  to pool/main/g/glibc/locales_2.3.5-4_all.deb
nscd_2.3.5-4_i386.deb
  to pool/main/g/glibc/nscd_2.3.5-4_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 321718@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
GOTO Masanori <gotom@debian.org> (supplier of updated glibc package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sat,  6 Aug 2005 06:52:42 +0900
Source: glibc
Binary: libc6-i686 libc6-dev-ppc64 libc0.3-pic glibc-doc libc1-udeb libc0.3 libc6.1-dev libc1-pic libc6-s390x libnss-files-udeb libc1-dbg libc6-dev-sparc64 libc0.3-dev libc6-udeb libc6-dbg libc6.1-pic libc6-dev libc0.3-prof libc6-sparcv9 libc6.1-prof libc1 locales libc6-pic libc0.3-udeb libc1-prof libc6-ppc64 libc0.3-dbg libc6-prof libc6 libc6-sparcv9b libc6.1-udeb libc6.1-dbg nscd libc6-sparc64 libnss-dns-udeb libc6.1 libc1-dev libc6-dev-s390x
Architecture: source i386 all
Version: 2.3.5-4
Distribution: unstable
Urgency: low
Maintainer: GOTO Masanori <gotom@debian.org>
Changed-By: GOTO Masanori <gotom@debian.org>
Description: 
 glibc-doc  - GNU C Library: Documentation
 libc6      - GNU C Library: Shared libraries and Timezone data
 libc6-dbg  - GNU C Library: Libraries with debugging symbols
 libc6-dev  - GNU C Library: Development Libraries and Header Files
 libc6-i686 - GNU C Library: Shared libraries [i686 optimized]
 libc6-pic  - GNU C Library: PIC archive library
 libc6-prof - GNU C Library: Profiling Libraries
 libc6-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libnss-dns-udeb - GNU C Library: NSS helper for DNS - udeb (udeb)
 libnss-files-udeb - GNU C Library: NSS helper for files - udeb (udeb)
 locales    - GNU C Library: National Language (locale) data [support]
 nscd       - GNU C Library: Name Service Cache Daemon
Closes: 321561 321712 321717 321718 321719 321740 321796 322506 322768 323352 323409 323487 323552 323560
Changes: 
 glibc (2.3.5-4) unstable; urgency=low
 .
   * The "hppa is important to someone, really - LaMont" release.
 .
   * GOTO Masanori <gotom@debian.org>
 .
     * d-i wants to remove libnss-files-udeb and libnss-dns-udeb dependency
       from libc-udeb.  Suggested by Joey Hess <joeyh@debian.org>.
       (Closes: #322506)
       - debian/control.in/libc: Remove libnss-files-udeb libnss-dns-udeb
         dependency.
       - debian/control: Update.
 .
     * Build-Depends fixes:
       - debian/control.in/main: Change gcc-* dependency from | to ,.
         Suggested by Andreas Jochens <aj@andaco.de>.
       - debian/control.in/main: Add gcc-4.0 (>= 4.0.1-5) [hppa], because prior
         versions cannot generate sane glibc binaries.
       - debian/control: Update.
 .
     * Enable libnss upgrade guard again.
       (Closes: #321561, #321712, #321796, #322768, #323560)
       - debian/debhelper.in/libc.preinst: Change guard to 2.3.5-1.
       - debian/debhelper.in/libc.postinst: Likewise.
       - debian/debhelper.in/libc.postinst: Fix to invoke NSS check again.
 .
     * debian/debhelper.in/nscd.dirs: Add /var/db/nscd.
       (Closes: #323352, #323487)
 .
     * debian/debhelper.in/locales.prerm: Add purge to remove locale-archive.
       (Closes: #321719)
 .
     * debian/patches/00list: Drop glibc234-hppa-remove-mallocdef.dpatch.
       It causes unconditional locking problem, because it was already replaced
       by Carlos' new patches.  Reported by LaMont Jones <lamont@debian.org>.
 .
     * Add Depends: lib64gcc1 and provide lib64c-dev for 64bit -dev packages.
       Suggested by Matthias Klose <doko@cs.tu-berlin.de>.  (Closes: #323552)
       - debian/control.in/sparc64: Likewise.
       - debian/control.in/ppc64: Likewise.
       - debian/control.in/s390x: Likewise.
       - debian/control: Update.
 .
     * debian/patches/glibc235-dl-execstack.dpatch: New file, to fix execstack
       failed to check on kernel <= 2.4.18.  (Closes: #321717, #321718, #323409)
 .
     * Roland Stigge <stigge@antcom.de>:
       - debian/debhelper.in/glibc-doc.install: Install HTML documents
         correctly.  (Closes: #321740)
Files: 
 b5f966da1bac2037f2c3250939665bf2 1733 libs required glibc_2.3.5-4.dsc
 cce2797679eb5a72552917205c58a8e2 294918 libs required glibc_2.3.5-4.diff.gz
 68c56229f8570af8f2f257cd3c2f3f2c 3330198 doc optional glibc-doc_2.3.5-4_all.deb
 37cb28ab4c4cfdd20ba8368f4fc98721 4057888 base standard locales_2.3.5-4_all.deb
 bb6dbd9475c74a4946092d32dcf9d148 4927430 base required libc6_2.3.5-4_i386.deb
 11c55fbdd91e3bb9bce31fa26f25dbea 2678864 libdevel standard libc6-dev_2.3.5-4_i386.deb
 79bbe3c04e2aa80abd32c23fa99aa053 1262672 libdevel extra libc6-prof_2.3.5-4_i386.deb
 7be8aef8e28c3ff7e6e8abcdbf6956ed 1010100 libdevel optional libc6-pic_2.3.5-4_i386.deb
 0448a23476d35e8d6b36d89648286b60 1006866 libs extra libc6-i686_2.3.5-4_i386.deb
 ff78ac9f175de45621c1fb49b734ca36 122578 admin optional nscd_2.3.5-4_i386.deb
 e7e7823b042a459c238a7bd4cbed6471 5945942 libdevel extra libc6-dbg_2.3.5-4_i386.deb
 2c946e6bf4c8f0d6d5f94da17597e30c 702862 debian-installer extra libc6-udeb_2.3.5-4_i386.udeb
 ccc70c566c634c19b44f53e309df03cd 8270 debian-installer extra libnss-dns-udeb_2.3.5-4_i386.udeb
 016ab73700c3956503915f65c7f06544 14856 debian-installer extra libnss-files-udeb_2.3.5-4_i386.udeb
package-type: udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDBdSoqIqasIZIJsMRAu/BAJ9JlI/xi3WXxvCOt9Ev7AqGTK9gbwCfSbz7
f6wWT3sxSMKyy/LsRc6s7cU=
=7XOJ
-----END PGP SIGNATURE-----

Message #134 received at 323409-close@bugs.debian.org (full text, mbox, reply):

From: GOTO Masanori <gotom@debian.org>

To: 323409-close@bugs.debian.org

Subject: Bug#323409: fixed in glibc 2.3.5-4

Date: Fri, 19 Aug 2005 06:17:17 -0700

Source: glibc
Source-Version: 2.3.5-4

We believe that the bug you reported is fixed in the latest version of
glibc, which is due to be installed in the Debian FTP archive:

glibc-doc_2.3.5-4_all.deb
  to pool/main/g/glibc/glibc-doc_2.3.5-4_all.deb
glibc_2.3.5-4.diff.gz
  to pool/main/g/glibc/glibc_2.3.5-4.diff.gz
glibc_2.3.5-4.dsc
  to pool/main/g/glibc/glibc_2.3.5-4.dsc
libc6-dbg_2.3.5-4_i386.deb
  to pool/main/g/glibc/libc6-dbg_2.3.5-4_i386.deb
libc6-dev_2.3.5-4_i386.deb
  to pool/main/g/glibc/libc6-dev_2.3.5-4_i386.deb
libc6-i686_2.3.5-4_i386.deb
  to pool/main/g/glibc/libc6-i686_2.3.5-4_i386.deb
libc6-pic_2.3.5-4_i386.deb
  to pool/main/g/glibc/libc6-pic_2.3.5-4_i386.deb
libc6-prof_2.3.5-4_i386.deb
  to pool/main/g/glibc/libc6-prof_2.3.5-4_i386.deb
libc6-udeb_2.3.5-4_i386.udeb
  to pool/main/g/glibc/libc6-udeb_2.3.5-4_i386.udeb
libc6_2.3.5-4_i386.deb
  to pool/main/g/glibc/libc6_2.3.5-4_i386.deb
libnss-dns-udeb_2.3.5-4_i386.udeb
  to pool/main/g/glibc/libnss-dns-udeb_2.3.5-4_i386.udeb
libnss-files-udeb_2.3.5-4_i386.udeb
  to pool/main/g/glibc/libnss-files-udeb_2.3.5-4_i386.udeb
locales_2.3.5-4_all.deb
  to pool/main/g/glibc/locales_2.3.5-4_all.deb
nscd_2.3.5-4_i386.deb
  to pool/main/g/glibc/nscd_2.3.5-4_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 323409@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
GOTO Masanori <gotom@debian.org> (supplier of updated glibc package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sat,  6 Aug 2005 06:52:42 +0900
Source: glibc
Binary: libc6-i686 libc6-dev-ppc64 libc0.3-pic glibc-doc libc1-udeb libc0.3 libc6.1-dev libc1-pic libc6-s390x libnss-files-udeb libc1-dbg libc6-dev-sparc64 libc0.3-dev libc6-udeb libc6-dbg libc6.1-pic libc6-dev libc0.3-prof libc6-sparcv9 libc6.1-prof libc1 locales libc6-pic libc0.3-udeb libc1-prof libc6-ppc64 libc0.3-dbg libc6-prof libc6 libc6-sparcv9b libc6.1-udeb libc6.1-dbg nscd libc6-sparc64 libnss-dns-udeb libc6.1 libc1-dev libc6-dev-s390x
Architecture: source i386 all
Version: 2.3.5-4
Distribution: unstable
Urgency: low
Maintainer: GOTO Masanori <gotom@debian.org>
Changed-By: GOTO Masanori <gotom@debian.org>
Description: 
 glibc-doc  - GNU C Library: Documentation
 libc6      - GNU C Library: Shared libraries and Timezone data
 libc6-dbg  - GNU C Library: Libraries with debugging symbols
 libc6-dev  - GNU C Library: Development Libraries and Header Files
 libc6-i686 - GNU C Library: Shared libraries [i686 optimized]
 libc6-pic  - GNU C Library: PIC archive library
 libc6-prof - GNU C Library: Profiling Libraries
 libc6-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libnss-dns-udeb - GNU C Library: NSS helper for DNS - udeb (udeb)
 libnss-files-udeb - GNU C Library: NSS helper for files - udeb (udeb)
 locales    - GNU C Library: National Language (locale) data [support]
 nscd       - GNU C Library: Name Service Cache Daemon
Closes: 321561 321712 321717 321718 321719 321740 321796 322506 322768 323352 323409 323487 323552 323560
Changes: 
 glibc (2.3.5-4) unstable; urgency=low
 .
   * The "hppa is important to someone, really - LaMont" release.
 .
   * GOTO Masanori <gotom@debian.org>
 .
     * d-i wants to remove libnss-files-udeb and libnss-dns-udeb dependency
       from libc-udeb.  Suggested by Joey Hess <joeyh@debian.org>.
       (Closes: #322506)
       - debian/control.in/libc: Remove libnss-files-udeb libnss-dns-udeb
         dependency.
       - debian/control: Update.
 .
     * Build-Depends fixes:
       - debian/control.in/main: Change gcc-* dependency from | to ,.
         Suggested by Andreas Jochens <aj@andaco.de>.
       - debian/control.in/main: Add gcc-4.0 (>= 4.0.1-5) [hppa], because prior
         versions cannot generate sane glibc binaries.
       - debian/control: Update.
 .
     * Enable libnss upgrade guard again.
       (Closes: #321561, #321712, #321796, #322768, #323560)
       - debian/debhelper.in/libc.preinst: Change guard to 2.3.5-1.
       - debian/debhelper.in/libc.postinst: Likewise.
       - debian/debhelper.in/libc.postinst: Fix to invoke NSS check again.
 .
     * debian/debhelper.in/nscd.dirs: Add /var/db/nscd.
       (Closes: #323352, #323487)
 .
     * debian/debhelper.in/locales.prerm: Add purge to remove locale-archive.
       (Closes: #321719)
 .
     * debian/patches/00list: Drop glibc234-hppa-remove-mallocdef.dpatch.
       It causes unconditional locking problem, because it was already replaced
       by Carlos' new patches.  Reported by LaMont Jones <lamont@debian.org>.
 .
     * Add Depends: lib64gcc1 and provide lib64c-dev for 64bit -dev packages.
       Suggested by Matthias Klose <doko@cs.tu-berlin.de>.  (Closes: #323552)
       - debian/control.in/sparc64: Likewise.
       - debian/control.in/ppc64: Likewise.
       - debian/control.in/s390x: Likewise.
       - debian/control: Update.
 .
     * debian/patches/glibc235-dl-execstack.dpatch: New file, to fix execstack
       failed to check on kernel <= 2.4.18.  (Closes: #321717, #321718, #323409)
 .
     * Roland Stigge <stigge@antcom.de>:
       - debian/debhelper.in/glibc-doc.install: Install HTML documents
         correctly.  (Closes: #321740)
Files: 
 b5f966da1bac2037f2c3250939665bf2 1733 libs required glibc_2.3.5-4.dsc
 cce2797679eb5a72552917205c58a8e2 294918 libs required glibc_2.3.5-4.diff.gz
 68c56229f8570af8f2f257cd3c2f3f2c 3330198 doc optional glibc-doc_2.3.5-4_all.deb
 37cb28ab4c4cfdd20ba8368f4fc98721 4057888 base standard locales_2.3.5-4_all.deb
 bb6dbd9475c74a4946092d32dcf9d148 4927430 base required libc6_2.3.5-4_i386.deb
 11c55fbdd91e3bb9bce31fa26f25dbea 2678864 libdevel standard libc6-dev_2.3.5-4_i386.deb
 79bbe3c04e2aa80abd32c23fa99aa053 1262672 libdevel extra libc6-prof_2.3.5-4_i386.deb
 7be8aef8e28c3ff7e6e8abcdbf6956ed 1010100 libdevel optional libc6-pic_2.3.5-4_i386.deb
 0448a23476d35e8d6b36d89648286b60 1006866 libs extra libc6-i686_2.3.5-4_i386.deb
 ff78ac9f175de45621c1fb49b734ca36 122578 admin optional nscd_2.3.5-4_i386.deb
 e7e7823b042a459c238a7bd4cbed6471 5945942 libdevel extra libc6-dbg_2.3.5-4_i386.deb
 2c946e6bf4c8f0d6d5f94da17597e30c 702862 debian-installer extra libc6-udeb_2.3.5-4_i386.udeb
 ccc70c566c634c19b44f53e309df03cd 8270 debian-installer extra libnss-dns-udeb_2.3.5-4_i386.udeb
 016ab73700c3956503915f65c7f06544 14856 debian-installer extra libnss-files-udeb_2.3.5-4_i386.udeb
package-type: udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDBdSoqIqasIZIJsMRAu/BAJ9JlI/xi3WXxvCOt9Ev7AqGTK9gbwCfSbz7
f6wWT3sxSMKyy/LsRc6s7cU=
=7XOJ
-----END PGP SIGNATURE-----

Message #139 received at 321718@bugs.debian.org (full text, mbox, reply):

From: Daniel Jacobowitz <drow@false.org>

To: Steve Langasek <vorlon@debian.org>

Cc: GOTO Masanori <gotom@debian.or.jp>, 321718@bugs.debian.org, Joe Mason <joe@notcharles.ca>

Subject: Re: Bug#321718: Upgrade caused many libs to complain about "executable stack"

Date: Mon, 22 Aug 2005 20:09:12 -0400

On Thu, Aug 18, 2005 at 03:03:01PM -0700, Steve Langasek wrote:
> On Thu, Aug 18, 2005 at 08:59:17PM +0900, GOTO Masanori wrote:
> 
> > This modification was done because mprotect returned EFAULT instead of
> > ENOMEM, that was simply POSIX violation.  The actual problem is linux
> > kernel 2.4.  But in order to work glibc 2.3.5 on etch, we need to fix
> > adhoc patch to change dl-execstack.c.  I don't know it's acceptable
> > for upstream, but it's worth fixing.  If it'll be rejected, this patch
> > should be marked as "until-etch" if etch does not support any 2.4
> > kernel hopefully.  Now the patch that I have not tested yet.  Is this
> > solution desired for the next 2.3.5-4?
> 
> Etch certainly won't support 2.4.18 officially; that will be an
> oldstable-1 kernel at the time etch releases.  Is it really worth trying
> to maintain compatibility with that kernel?
> 
> AIUI, glibc 2.3.5 is currently compatible with the sarge and etch 2.4
> kernels.  That seems sufficient to me; why not just mark glibc in the
> preinst as being incompatible with old 2.4 kernels?

I'm fine with either of these solutions.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Send a report that this bug log contains spam.