Bug#1014662: cloud-initramfs-growroot: Initramfs hook does not include `flock` command

[Shane Frasier]

Dear Maintainer,

I am seeing exactly this same issue in Kali Linux, which uses the Debian
Bullseye package.  This is causing our AMIs (which use the official Kali
AMI as the base) to fail to boot.

Thank you,
Shane Frasier

On Sun, 10 Jul 2022 11:25:41 +1000 undef  wrote:
>
> Package: cloud-initramfs-growroot
> Version: 0.18.debian8
> Severity: important
> Tags: upstream
> X-Debbugs-Cc: debian@undef.tools
>
> Dear Maintainer,
>
> As part of the standard Mobian install proceedure, we use
> cloud-initramfs-growroot to expand the root partition on the device.
> Recent installs have been failing to resize with the following (debug)
> output:
> ```
> + growpart /dev/mmcblk0 2
> + out='failed [flock:127] flock -x 9
> /sbin/growpart: line 714: flock: not found
> FAILED: Error while obtaining exclusive lock on /dev/mmcblk0'
> + echo 'GROWROOT: WARNING: resize failed: failed [flock:127] flock -x 9
> /sbin/growpart: line 714: flock: not found
> FAILED: Error while obtaining exclusive lock on /dev/mmcblk0'
> GROWROOT: WARNING: resize failed: failed [flock:127] flock -x 9
> /sbin/growpart: line 714: flock: not found
> FAILED: Error while obtaining exclusive lock on /dev/mmcblk0
> + udevadm settle --timeout 30
> ```
>
> I believe this issue is solved upstream where the hook has been
> re-written
> (
https://git.launchpad.net/cloud-initramfs-tools/tree/growroot/hooks/growroot#n12
).
>
> Without updating to the latest upstream version, simply adding
> `copy_exec /bin/flock /bin` to the growroot hook also solves the issue.
>
> Thank you for your consideration.
>
>
> -- System Information:
> Debian Release: bookworm/sid
>APT prefers testing
>APT policy: (500, 'testing')
> Architecture: arm64 (aarch64)
>
> Kernel: Linux 5.18.7-rockchip (SMP w/6 CPU threads)
> Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages cloud-initramfs-growroot depends on:
> pn  cloud-utils  
> ii  fdisk2.38-4
> ii  initramfs-tools  0.141
> ii  util-linux   2.38-4
>
> cloud-initramfs-growroot recommends no packages.
>
> cloud-initramfs-growroot suggests no packages.
>

Bug#1011070: sssd-ad-common: Binary linked against an old version of so

[Shane Frasier]

Hello,

I was able to get past this, and I think this bug can be closed.
Normally when I install packages from backports I use a command like
"apt-get install -t bullseye-backports freeipa-client", but in this
case there is no freeipa-client package in the main bullseye package
repo.  Therefore, I was able to run the command "apt-get install
freeipa-client" to install freeipa-client from backports but all
dependencies from the non-backports package repos where possible.

Thank you,
Shane Frasier

Bug#1011070: sssd-ad-common: Binary linked against an old version of so

[Shane Frasier]

Package: sssd-ad-common
Version: 2.4.1-2
Severity: important
X-Debbugs-Cc: maver...@maverickdolphin.com

Dear Maintainer,

When I set up FreeIPA client on a new and fully upgraded Debian
Bullseye server, I find that the sssd service fails to start.  Uopn
investigation, I found that the issue was that the binary file
/usr/libexec/sssd/sssd_pac is linked against libndr.so.1, while the
dependency samba-libs now provides libndr.so.2.  You can confrim this
via the command ldd /usr/libexec/sssd/sssd_pac.

I believe the issue could be remedied by rebuilding the sssd-ad-common
package, although it is possible that other packages from the same
source package would need to be rebuilt as well.

I have rebuilt Debian packages in the past and successfully submitted
them to backports, but I have not previously attempted to submit a
bugfix like this.  I'm happy to do so if someone can point me toward
the prelevant documentation.

Thank you,
Shane

-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-14-cloud-amd64 (SMP w/2 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sssd-ad-common depends on:
ii  libc6  2.31-13+deb11u3
ii  libldb22:2.5.0+smb4.16.1-3~bpo11+3
ii  libpopt0   1.18-2
ii  libselinux13.1-3
ii  libsss-idmap0  2.4.1-2
ii  libsystemd0247.3-7
ii  libtalloc2 2.3.3-4~bpo11+1
ii  libtdb11.4.6-3~bpo11+1
ii  libtevent0 0.11.0-1~bpo11+1
ii  samba-libs 2:4.16.1+dfsg-3~bpo11+3
ii  sssd-common2.4.1-2

sssd-ad-common recommends no packages.

sssd-ad-common suggests no packages.

-- no debconf information

Bug#986419: Bug can be closed

[Shane Frasier]

This bug can be closed now that a newer version exists in buster-backports
.

Bug#987265: stunnel4: Bug in patch file 04-restore-pidfile-default.patch

[Shane Frasier]

Package: stunnel4
Version: 3:5.50-3
Severity: important

Dear Maintainer,

When running AWS efs-utils( https://github.com/aws/efs-utils), which relies on
stunnel4, I see a lot of syslog messages of the form:
  stunnel: INTERNAL ERROR: Bad magic at options.c, line 1035

This message appears to be due to lines 28-29 of
debian/patches/04-restore-pidfile-default.patch:
-new_global_options.pidfile=NULL; /* do not create a pid file */
+new_global_options.pidfile=PIDFILE;

I think these lines should instead be:
-new_global_options.pidfile=NULL; /* do not create a pid file */
+new_global_options.pidfile=str_dup(PIDFILE)

This is because, when a SIGHUP signal is received, stunnel will attempt
to reload the configuration file.  In the process of doing that it will
call str_free() on the pidfile path string, as shown in the CMD_FREE
case clause of the same switch statement to which the above patch lines
apply.  (This case clause corresponds to lines 1051-1055 of the
unpatched file src/options.c.)

This bug seems like it could cause memory corruption issues, so I
labeled it as important.  Feel free to change the severity if this was
incorrect.

I didn't find this bug already reported in BTS, but I did find it
reported in Ubuntu's bug tracker:
https://bugs.launchpad.net/ubuntu/+source/stunnel4/+bug/1901784

I also verified that this bug is still in the testing and unstable
version of the stunnel4 package (3:5.56+dfsg-9).

Thank you,
Shane Frasier


-- System Information:
Debian Release: 10.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-16-cloud-amd64 (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages stunnel4 depends on:
ii  adduser  3.118
ii  libc62.28-10
ii  libssl1.11.1.1d-0+deb10u6
ii  libsystemd0  241-7~deb10u7
ii  libwrap0 7.6.q-28
ii  lsb-base 10.2019051400
ii  netbase  5.6
ii  openssl  1.1.1d-0+deb10u6
ii  perl 5.28.1-6+deb10u1

stunnel4 recommends no packages.

Versions of packages stunnel4 suggests:
pn  logcheck-database  

-- no debconf information

Bug#987024: RFS: python-docker/4.1.0-1.2~bpo10 1 [NMU] [RC] -- Python 3 wrapper to access docker.io's control socket

[Shane Frasier]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "python-docker":

 * Package name: python-docker
   Version : 4.1.0-1.2~bpo10+1
   Upstream Author : Docker, Inc.
 * URL : https://github.com/docker/docker-py
 * License : Apache-2.0
 * Vcs :
https://salsa.debian.org/docker-compose-team/python-docker
   Section : python

I created this backport because I need it in order to create a backport for
docker-compose.  I want to create a backport for docker-compose because my
project requires a more recent version of docker-compose than is currently
available in Buster.

It builds those binary packages:

  python3-docker - Python 3 wrapper to access docker.io's control socket

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/python-docker/

Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/p/python-docker/python-docker_4.1.0-1.2~bpo10+1.dsc

Changes since the last upload:

 python-docker (4.1.0-1.2~bpo10+1) buster-backports; urgency=medium
 .
   * Rebuild for buster-backports.
 .
 python-docker (4.1.0-1.2) unstable; urgency=medium
 .
   * Uploading source-only.
 .
 python-docker (4.1.0-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Add python3-distutils runtime depends. (Closes: #958577)
 .
 python-docker (4.1.0-1) unstable; urgency=medium
 .
   * New upstream version 4.1.0
 - Refresh patches
   * Use secure copyright file specification URI.
   * Set upstream metadata fields: Repository.
   * Bump debhelper from old 10 to 12.
   * Bump Standards Version
   * Drop Python3-Version field.
 Minimum required version is shipped in oldstable
 .
 python-docker (3.4.1-4.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Drop python2 support; Closes: #937714

Regards,
Shane Frasier

Bug#986419: python3-botocore: Version of python3-botocore in stable does not support IMDSv2

[Shane Frasier]

Package: python3-botocore
Version: 1.12.103+repack-1
Severity: normal

Dear Maintainer,

Version 1.12.103 of this package is sufficiently old that it does not
support the more secure IMDSv2.  Is it possible to get the testing 
version (1.20.0) into stable-backports?  This seems like it would help 
many (especially cloud) users.

I'm able to build a new deb package for stable-backports using the
instructions here:
https://wiki.debian.org/BuildingFormalBackports
I can't upload it, though, since I'm new to Debian contribution process.
I'm happy to help in any way I can.

Thanks,
Shane


-- System Information:
Debian Release: 10.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-16-cloud-amd64 (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-botocore depends on:
ii  python3   3.7.3-1
ii  python3-dateutil  2.7.3-3
ii  python3-docutils  0.14+dfsg-4
ii  python3-jmespath  0.9.4-1
ii  python3-requests  2.21.0-1
ii  python3-urllib3   1.24.1-1

python3-botocore recommends no packages.

python3-botocore suggests no packages.

-- no debconf information

Bug#966846: Kernel panic (4.19.0-10): RIP __cgroup_bpf_run_filter_skb

[Shane Frasier]

3551] PGD 0 P4D 0
[  478.696291] Oops:  [#1] SMP PTI
[  478.699431] CPU: 0 PID: 1453 Comm: sshd Kdump: loaded Not tainted
4.19.0-10-cloud-amd64 #1 Debian 4.19.132-1
[  478.706782] Hardware name: Amazon EC2 t3.medium/, BIOS 1.0 10/16/2017
[  478.711129] RIP: 0010:__cgroup_bpf_run_filter_skb+0xbd/0x1e0
[  478.715172] Code: 00 00 00 49 89 7f 18 48 89 0c 24 44 89 e1 48 29 c8 48
89 4c 24 08 49 89 87 d8 00 00 00 89 d2 48 8d 84 d6 b0 03 00 00 48 8b 00
<48> 8b 58 10 4c 8d 70 10 48 85 db 0f 84 01 01 00 00 4d 8d 6f 30 bd
[  478.727711] RSP: 0018:b37740c77ad0 EFLAGS: 00010286
[  478.731595] RAX:  RBX: 8a3ff55e5ee8 RCX:

[  478.736351] RDX: 0001 RSI: 8a3ff3d49800 RDI:
8a3ff52fd500
[  478.741042] RBP: 8a3ff52fd500 R08: 8a3ff55e5ee8 R09:
0001
[  478.745697] R10: 0001 R11: 8a3ef6dd7500 R12:

[  478.750446] R13:  R14: 8a3ff52fd840 R15:
8a3ff55e5ee8
[  478.755161] FS:  7fd74bb17e40() GS:8a3ff7e0()
knlGS:
[  478.761724] CS:  0010 DS:  ES:  CR0: 80050033
[  478.765853] CR2: 0010 CR3: a94e6005 CR4:
007606b0
[  478.770524] DR0:  DR1:  DR2:

[  478.775273] DR3:  DR6: fffe0ff0 DR7:
0400
[  478.779984] PKRU: 5554
[  478.782901] Call Trace:
[  478.785756]  ip_finish_output+0x228/0x270
[  478.789204]  ? nf_hook_slow+0x44/0xc0
[  478.792490]  ip_output+0x6c/0xe0
[  478.795685]  ? ip_append_data.part.49+0xd0/0xd0
[  478.799403]  __ip_queue_xmit+0x15d/0x410
[  478.802945]  ? set_fd_set.part.7+0x40/0x40
[  478.806411]  __tcp_transmit_skb+0x527/0xb10
[  478.810032]  tcp_write_xmit+0x384/0x1000
[  478.813636]  ? _copy_from_iter_full+0x94/0x240
[  478.817438]  __tcp_push_pending_frames+0x31/0xd0
[  478.821170]  tcp_sendmsg_locked+0xc1c/0xd50
[  478.824714]  tcp_sendmsg+0x27/0x40
[  478.827921]  sock_sendmsg+0x36/0x40
[  478.831280]  sock_write_iter+0x97/0x100
[  478.834714]  new_sync_write+0xfb/0x160
[  478.838010]  vfs_write+0xa5/0x1a0
[  478.841129]  ksys_write+0x57/0xd0
[  478.844250]  do_syscall_64+0x50/0xf0
[  478.847526]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  478.851385] RIP: 0033:0x7fd74beba504
[  478.854598] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80
00 00 00 00 48 8d 05 f9 61 0d 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05
<48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 49 89 d4 55 48 89 f5 53
[  478.867315] RSP: 002b:7ffc1d456638 EFLAGS: 0246 ORIG_RAX:
0001
[  478.873758] RAX: ffda RBX: 0084 RCX:
7fd74beba504
[  478.878456] RDX: 0084 RSI: 55785f33bb90 RDI:
0003
[  478.883176] RBP: 55785f31d630 R08:  R09:
1000
[  478.887885] R10: 0008 R11: 0246 R12:
01dd
[  478.892646] R13: 55785ddc9b00 R14: 0003 R15:
7ffc1d4566e0
[  478.897480] Modules linked in: xt_nat xt_tcpudp veth xt_conntrack
ipt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo nft_counter
xt_addrtype nft_compat nft_chain_nat_ipv4 nf_nat_ipv4 nf_nat nf_conntrack
nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c nf_tables nfnetlink br_netfilter
bridge stp llc binfmt_misc overlay crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel nls_ascii nls_cp437 vfat fat intel_rapl_perf evdev
serio_raw button ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2
crc32c_generic fscrypto ecb crc32c_intel aesni_intel nvme aes_x86_64
crypto_simd ena nvme_core cryptd glue_helper
[  478.931979] CR2: 0010

Let me know if I can provide any other information that may be of use.

Shane Frasier