Subject: libc6: Permission denied, intermittent in execve

From: Alessandro Vesely <[email-masked]>
Date: Mon, 27 Jul 2020 10:25:27 +0200

Package: libc6
Version: GNU C Library (Debian GLIBC 2.28-10) stable release version 2.28.
Severity: normal

Dear Maintainer,

in certain situations, execve fails setting errno to EACCESS.  The same
program, launched by the same user in different ways, succeeds or fails
according to preceding actions.

None of the failure conditions for EACCESS is met.

The case at hand happens with an old version of Thunderbird and a LibreOffice
attachment.  After saving the attachment, Thunderbird execs gio-launch-desktop.
The latter tries to exec libreoffice6.4 and fails.

I strace'd the full arguments used in the failed execve(), and copied them to a
simple C program which runs just that execve() call.  When called from the
command line, the program succeeds.  Then I replaced the gio-launch-desktop
executable with my straw men.  When called from Thunderbird, the program fails.

See also:
https://unix.stackexchange.com/questions/600174/permission-denied-intermittent-
in-execve

-- System Information:
Distributor ID: Debian
Description:    Devuan GNU/Linux 3 (beowulf)
Release:        3
Codename:       beowulf
Architecture: x86_64

Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8),
LANGUAGE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

---

From: Mark Hindley <[email-masked]>
Date: Mon, 27 Jul 2020 10:14:01 +0100

Control: forcemerge 498 497
Control: tags -1 debian
Control: forwarded -1 https://bugs.debian.org/966343

Alessandro

On Mon, Jul 27, 2020 at 10:32:15AM +0200, Alessandro Vesely wrote:
> -------- Forwarded Message --------
> Subject: libc6: Permission denied, intermittent in execve
> Date: Mon, 27 Jul 2020 10:25:27 +0200
> From: Alessandro Vesely <[email-masked]>
> To: Devuan Bug Tracking System <[email-masked]>
> 
> 
> Dear Maintainer,
> 

Thanks for this. As you have realised, libc6 is a Debian package that Devuan
uses directly without recompilation so this issue is correctly dealt with in
Debian's BTS.

However, one thought that occurs to me is whether apparmor is causing this? Does
disabling it[1] restore predictable behaviour?

Thanks.

Mark

[1]  https://wiki.debian.org/AppArmor/HowToUse#Diagnose_if_a_bug_might_have_been_caused_by_AppArmor

---

From: Mark Hindley <[email-masked]>
Date: Mon, 27 Jul 2020 10:17:48 +0100

found 498 2.28-10