Bug#966343: marked as done (libc6: Permission denied, intermittent in execve)
Your message dated Wed, 29 Jul 2020 00:14:54 +0200
with message-id <20200728221454.GJ8215@aurel32.net>
and subject line Re: Bug#966343: bug#498: libc6: Permission denied, intermittent in execve
has caused the Debian Bug report #966343,
regarding libc6: Permission denied, intermittent in execve
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)
--
966343: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966343
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: libc6
Version: GNU C Library (Debian GLIBC 2.28-10) stable release version 2.28.
Severity: normal
-------- Forwarded Message --------
Subject: libc6: Permission denied, intermittent in execve
Date: Mon, 27 Jul 2020 10:25:27 +0200
From: Alessandro Vesely <vesely@tana.it>
To: Devuan Bug Tracking System <submit@bugs.devuan.org>
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
--- End Message ---
--- Begin Message ---
Hi,
On 2020-07-27 19:01, Alessandro Vesely wrote:
> On Mon, 27 Jul 2020 12:13:44 +0200 Samuel Thibault <sthibault@debian.org> wrote:
> > Alessandro Vesely, le lun. 27 juil. 2020 11:47:34 +0200, a ecrit:
> > > So this turns out to be a documentation bug. The execve man page should mention that EACCESS can result as an (unforeseen) apparmor impediment.
> >
> > Well, basically all system calls would then need this...
>
>
> Yeah, likely. How many man pages have snippets like "[...] denied for one of the directories in the path [...]"?
>
> Yet, considering the following examples, they seem to have been written manually rather than resorting to some sort of script:
There are many syscalls that might end up returning EACCESS. Mapping
them to the corresponding libc functions might not be always fully
linear.
[snip]
> Philip Couling commented that the man page /could/ mention security extensions since they are prevelent. See:
> https://unix.stackexchange.com/questions/600174/identical-execve-causes-permission-denied-for-one-program-but-not-another/600529#comment1121270_600529
>
> For execve, for example, one could add that permissions are not derived from file flags only. For example:
>
> OLD:
>
> EACCES Execute permission is denied for the file or a script or ELF interpreter.
>
> NEW:
>
> EACCES Execute permission for the file or a script or ELF interpreter is denied either by flags or by security modules.
>
>
> Would that be correct? Do all "DENIED" operations result in EACCES? And what do other security modules do? Hmm... Starting to document that mess from the point of view of programs getting such failure codes would allow better logging and better troubleshooting.
That seems correct for apparmor (although it can also return ENOENT in
case of race condition), not sure about other security modules. seccomp
just kills the process, not sure you want to mention that in every
possible manpages.
In any case this is now out of scope for the glibc package, so I am
closing the bug. If you feel that the doc needs to be updated, please
open a bug against the corresponding package.
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
--- End Message ---
Reply to: