schroot fails for source chroots with 'std:bad_alloc' on groovy

[Alex Murray]

After upgrading to groovy or installing fresh from the beta, schroot fails to enter a source: chroot with std:bad_alloc:

$ schroot -c source:bionic-amd64
E: std::bad_alloc

Running this with debugging symbols under gdb we get the following backtrace:

amurray@slate:~$ gdb --ex='break std::bad_alloc::bad_alloc()' --ex=run --args schroot -c source:bionic-amd64
GNU gdb (Ubuntu 9.2-0ubuntu2) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from schroot...
Reading symbols from /usr/lib/debug/.build-id/70/4469864df39ed3af1f8a23bd8d27adffeb8315.debug...
Catchpoint 1 (throw)
Function "std::bad_alloc::bad_alloc()" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (std::bad_alloc::bad_alloc()) pending.
Starting program: /usr/bin/schroot -c source:bionic-amd64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Catchpoint 1 (exception thrown), 0x00007fd231965762 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt full
#0 0x00007fd231965762 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#1 0x00007fd231959562 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#2 0x00005596c26b8a2f in __gnu_cxx::new_allocator<char>::allocate (this=0x7ffd3b189dd0, __n=34359738368) at /usr/include/c++/9/ext/new_allocator.h:102
No locals.
#3 std::allocator_traits<std::allocator<char> >::allocate (__a=..., __n=34359738368) at /usr/include/c++/9/bits/alloc_traits.h:444
No locals.
#4 std::_Vector_base<char, std::allocator<char> >::_M_allocate (this=0x7ffd3b189dd0, __n=34359738368) at /usr/include/c++/9/bits/stl_vector.h:343
No locals.
#5 std::vector<char, std::allocator<char> >::reserve (this=this@entry=0x7ffd3b189dd0, __n=__n@entry=34359738368) at /usr/include/c++/9/bits/vector.tcc:78
        __old_size = 0
        __tmp = <optimised out>
#6 0x00005596c26b5996 in sbuild::group::query_name (this=0x7ffd3b189db0, name=0x5596c2c558c0 "admin") at ./sbuild/sbuild-util.cc:770
        size = 34359738368
        error = <optimised out>
        grp_result = 0x0
#7 0x00005596c26b5abf in sbuild::group::query_name (name=..., this=0x7ffd3b189db0) at /usr/include/c++/9/bits/basic_string.h:2300
No locals.
#8 sbuild::group::group (this=0x7ffd3b189db0, name=...) at ./sbuild/sbuild-util.cc:717
No locals.
#9 0x00005596c26a463f in sbuild::session::is_group_member (this=<optimised out>, groupname="admin") at ./sbuild/sbuild-session.cc:390
        grp = {<group> = {gr_name = 0x7fd1b0416010 <error: Cannot access memory at address 0x7fd1b0416010>, gr_passwd = 0x7fd1b041601e <error: Cannot access memory at address 0x7fd1b041601e>, gr_gid = 138,
            gr_mem = 0x7fd1b0416028}, buffer = std::vector of length 0, capacity 17179869184, valid = false}
        group_member = <optimised out>
        __PRETTY_FUNCTION__ = <optimised out>
#10 0x00005596c26a49eb in sbuild::session::get_chroot_membership (this=0x5596c2c329f0, chroot=..., in_users=@0x7ffd3b189e94: false, in_root_users=@0x7ffd3b189e95: false, in_groups=@0x7ffd3b189e96: false,
    in_root_groups=@0x7ffd3b189e97: true) at ./sbuild/sbuild-session.cc:475
        gp = "admin"
        users = std::vector of length 0, capacity 0
        root_users = <optimised out>
        groups = <optimised out>
        root_groups = std::vector of length 3, capacity 3 = {"root", "sbuild", "admin"}
        upos = <optimised out>
        rupos = <optimised out>
#11 0x00005596c26a4cd1 in sbuild::session::get_chroot_auth_status (this=0x5596c2c329f0, status=sbuild::auth::STATUS_NONE, chroot=...) at ./sbuild/sbuild-session.cc:496
        in_users = false
        in_root_users = false
        in_groups = false
        in_root_groups = true
#12 0x00005596c26a3ae1 in sbuild::session::get_auth_status (this=0x5596c2c329f0) at ./sbuild/sbuild-session.cc:554
        cur = {alias = "source:bionic-amd64", chroot = std::shared_ptr<sbuild::chroot> (use count 4, weak count 1) = {get() = 0x5596c2c51b80}}
        status = sbuild::auth::STATUS_NONE
        __PRETTY_FUNCTION__ = <optimised out>
#13 0x00005596c26a3fba in sbuild::session::run (this=0x5596c2c329f0) at /usr/include/c++/9/bits/shared_ptr_base.h:1020
No locals.
#14 0x00005596c2731fb9 in schroot::main_base::run_impl (this=0x7ffd3b18a180) at /usr/include/c++/9/bits/shared_ptr_base.h:1020
        __PRETTY_FUNCTION__ = "virtual int schroot::main_base::run_impl()"
        sess_op = <optimised out>
#15 0x00005596c272b392 in schroot_base::main::run (this=0x7ffd3b18a180, argc=<optimised out>, argv=0x7ffd3b18a3a8) at ./bin/schroot-base/schroot-base-main.cc:107
        status = <optimised out>
#16 0x00005596c269a2f0 in schroot_base::run<schroot::options, schroot::main> (argc=3, argv=0x7ffd3b18a3a8) at /usr/include/c++/9/bits/shared_ptr_base.h:1388
        opts = std::shared_ptr<schroot::options_base> (use count 3, weak count 0) = {get() = 0x5596c2c2cce0}
        kit = {<schroot::main_base> = {<schroot_base::main> = {_vptr.main = 0x5596c2778200 <vtable for schroot::main+16>, program_name = "schroot",
              program_usage = "[OPTION…] [COMMAND] — run command or shell in a chroot", program_options = std::shared_ptr<schroot_base::options> (use count 3, weak count 0) = {get() = 0x5596c2c2cce0},
              use_syslog = true}, options = std::shared_ptr<schroot::options_base> (use count 3, weak count 0) = {get() = 0x5596c2c2cce0}, config =

This shows sbuild is querying for the group 'admin' - however this does not exist on my groovy install:

amurray@slate:~$ getent group | grep ^admin
amurray@slate:~$

The reason it is checking for admin comes from the following 2 references for setting up schroot etc - https://wiki.ubuntu.com/SimpleSbuild and https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment#Creating_the_schroots - these both suggest creating a ~/.mk-sbuild.rc with the following entry:

SCHROOT_CONF_SUFFIX="source-root-users=root,sbuild,admin
source-root-groups=root,sbuild,admin
preserve-environment=true"

So in this case, sbuild will allow users in the root, sbuild or admin groups to be root in the source schroot.

The actual failure seems to be because the sbuild code does not check for appropriate errors from getpwnam_r / getpwuid_r - in sbuild-utilc.cc there is 4 variants of code like:

  while ((error = getgrnam_r(name, this,
                             &buffer[0], buffer.capacity(),
                             &grp_result)))
    {
      size <<= 1;
      buffer.reserve(size);
    }

However, this should only try and reallocate a larger buffer if these return ERANGE. Otherwise, if it fails for some other reason (like the group does not exist) it will continue to try and allocate a larger and larger buffer until it fails due to lack of memory.

This would appear to be the same bug as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763896 and whilst according to that bug it was fixed in schroot git upstream, perhaps this never made it into a debian and hence Ubuntu release?

[Roger Leigh (rleigh)]

Hi Alex,This is failing here:https://gitlab.com/codelibre/schroot/-/blob/schroot-1.6/sbuild/sbuild-util.cc#L757Is there something unusual about the group being checked?  getgrnam_r has returned ERANGE and schroot increased the buffer size to accommodate this until it ran out of memory.  The cause of failure is clear but the reason is not.Are you using LDAP, AD or is this all local users and groups?Kind regards,Roger Leigh
-------- Original message --------From: Alex Murray <email address hidden> Date: 12/10/2020 06:20 (GMT+00:00) To: <email address hidden> Subject: [Bug 1899414] [NEW] schroot fails for source chroots with
  'std:bad_alloc' on groovy Public bug reported:After upgrading to groovy or installing fresh from the beta, schrootfails to enter a source: chroot with std:bad_alloc:$ schroot -c source:bionic-amd64E: std::bad_allocRunning this with debugging symbols under gdb we get the followingbacktrace:amurray@slate:~$ gdb --ex='break std::bad_alloc::bad_alloc()' --ex=run --args schroot -c source:bionic-amd64GNU gdb (Ubuntu 9.2-0ubuntu2) 9.2Copyright (C) 2020 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>This is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law.Type "show copying" and "show warranty" for details.This GDB was configured as "x86_64-linux-gnu".Type "show configuration" for configuration details.For bug reporting instructions, please see:<http://www.gnu.org/software/gdb/bugs/>.Find the GDB manual and other documentation resources online at:    <http://www.gnu.org/software/gdb/documentation/>.For help, type "help".Type "apropos word" to search for commands related to "word"...Reading symbols from schroot...Reading symbols from /usr/lib/debug/.build-id/70/4469864df39ed3af1f8a23bd8d27adffeb8315.debug...Catchpoint 1 (throw)Function "std::bad_alloc::bad_alloc()" not defined.Make breakpoint pending on future shared library load? (y or [n]) yBreakpoint 2 (std::bad_alloc::bad_alloc()) pending.Starting program: /usr/bin/schroot -c source:bionic-amd64[Thread debugging using libthread_db enabled]Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".Catchpoint 1 (exception thrown), 0x00007fd231965762 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6(gdb) bt full#0  0x00007fd231965762 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6No symbol table info available.#1  0x00007fd231959562 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6No symbol table info available.#2  0x00005596c26b8a2f in __gnu_cxx::new_allocator<char>::allocate (this=0x7ffd3b189dd0, __n=34359738368) at /usr/include/c++/9/ext/new_allocator.h:102No locals.#3  std::allocator_traits<std::allocator<char> >::allocate (__a=..., __n=34359738368) at /usr/include/c++/9/bits/alloc_traits.h:444No locals.#4  std::_Vector_base<char, std::allocator<char> >::_M_allocate (this=0x7ffd3b189dd0, __n=34359738368) at /usr/include/c++/9/bits/stl_vector.h:343No locals.#5  std::vector<char, std::allocator<char> >::reserve (this=this@entry=0x7ffd3b189dd0, __n=__n@entry=34359738368) at /usr/include/c++/9/bits/vector.tcc:78     ...

[Roger Leigh (rleigh)]

Hi Alex,

Looking any https://gitlab.com/codelibre/schroot/-/blame/schroot-1.6/sbuild/sbuild-util.cc#L757 <https://gitlab.com/codelibre/schroot/-/blame/schroot-1.6/sbuild/sbuild-util.cc#L757>

and this commit:

https://gitlab.com/codelibre/schroot/-/commit/83bc6d3f99b1aa04a4864faeeb867ed09bae8e55

It looks like if this hasn’t been picked up, it should be. Maybe a new schroot point release is in order; schroot isn’t currently a high priority, I’m afraid.

Kind regards,
Roger

[Alex Murray (alexmurray)]

Hi Roger, this is all local users, no AD/LDAP etc.

[Matthias Klose (doko)]

uploaded the proposed fix, waiting for review

[Launchpad Janitor (janitor)]

This bug was fixed in the package schroot - 1.6.10-11ubuntu1

---------------
schroot (1.6.10-11ubuntu1) groovy; urgency=medium

  * schroot: util: Fix infinite allocation on error in name queries.
    LP: #1899414.

 -- Matthias Klose <email address hidden> Mon, 12 Oct 2020 14:19:36 +0200

[Alex Murray (alexmurray)]

Thanks doko, I can confirm that schroot 1.6.10-11ubuntu1 resolves this issue for me on groovy.