Followup post:
After further prodding and asking around, the answer turns out to be
"for some strange reason, on some of my systems, sudo/su are mapping a
bunch of additional libraries, including the application library you
were originally playing with (libzfs), so the crashing on exit when
you've overwritten one of the mapped libraries is expected behavior".

While I still would like to know why, precisely, sudo and su are
mapping apparently-unrelated libraries dynamically, this is no longer
surprising behavior, given the discovery that it's mapping in
superfluous libraries for fun.

Thanks to anyone who read the above longwinded writeup,
- Rich

On Wed, May 5, 2021 at 12:37 AM Rich <rincebr...@gmail.com> wrote:
>
> Hi all,
> reportbug pointed me here because I wasn't sure where to file this
> bug. I'll start by summarizing the observed behavior, and then go into
> more detail below.
>
> If anyone can suggest further debugging steps to take (or where to
> direct a bug report), I'd be grateful. :)
>
> $ sudo -i
> # cp /lib/x86_64-linux-gnu/libz.so.1.2.11 /tmp/
> # cp /tmp/libz.so.1.2.11 /lib/x86_64-linux-gnu/libz.so.1.2.11
> # exit
> logout
> Segmentation fault
> $
>
> I first encountered this behavior on a Debian bullseye VM running in
> VirtualBox on a non-ECC (Intel Coffee Lake) host. I then created an
> entirely new Debian bullseye VM from install media [1] on another
> ECC-having (Intel Broadwell) host using KVM, and reproduced this
> behavior. So if it's a bug in virtualization software, it's not just
> one implementation.
>
> The segfault in question does not occur if a cp is not performed to
> one of a number of possible library files in /lib/x86_64-linux-gnu/ -
> it does not appear to be all of them, as I tested with libanl-2.31.so
> and it did not cause a segfault on exit, but I do not know what the
> requirements are.
>
> The behavior in question is not specific to libz.so.1.2.11 somehow,
> that was just a convenient example - I originally encountered this
> when I was iterating on development of a different library by cping
> the recompiled library over and wondering why my sudo cp [...]
> segfaulted after completion. (Said software I was working on has never
> been installed on the KVM VM, so I think it's safe to say that it's
> unrelated to the problem.)
>
> I also reproduced this behavior on a CentOS 8 VM running on the same
> aforementioned VirtualBox host, but not a Debian buster VM on same.
>
> The behavior persists across cold and warm power cycles of the VM.
>
> While experimenting with someone in #debian, I tried installing sudo
> from experimental, and it still died the same way.
>
> I quickly tried building sudo from buster on bullseye, and it still
> dies the same way as well.
>
> "debsums" reports nothing but "OK" on either bullseye VM.
>
> Curiously, "su - root -c 'cp [...]'" segfaults on the VirtualBox VM
> but not the KVM VM.
>
> Thanks,
> - Rich
>
> [1] - debian-bullseye-DI-alpha3-amd64-netinst.iso, if curious

Reply via email to