Devuan bug report logs - #498
libc6: Permission denied, intermittent in execve

version graph

Package: libc6; Maintainer for libc6 is (unknown);

Reported by: Alessandro Vesely <vesely@tana.it>

Date: Mon, 27 Jul 2020 08:48:01 UTC

Severity: normal

Tags: debian

Merged with 497

Found in version 2.28-10

Forwarded to https://bugs.debian.org/966343

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to devuan-bugs@lists.dyne.org, devuan-dev@lists.dyne.org:
bug#498; Package libc6. (Mon, 27 Jul 2020 08:48:01 GMT) (full text, mbox, link).


Acknowledgement sent to Alessandro Vesely <vesely@tana.it>:
New bug report received and forwarded. Copy sent to devuan-dev@lists.dyne.org.

Your message had a Version: pseudo-header with an invalid package version:

GNU C Library (Debian GLIBC 2.28-10) stable release version 2.28.

please either use found or fixed to the control server with a correct version, or reply to this report indicating the correct version so the maintainer (or someone else) can correct it for you.

(Mon, 27 Jul 2020 08:48:04 GMT) (full text, mbox, link).


Message #5 received at submit@bugs.devuan.org (full text, mbox, reply):

From: Alessandro Vesely <vesely@tana.it>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Cc: Devuan Bug Tracking System <submit@bugs.devuan.org>
Subject: libc6: Permission denied, intermittent in execve
Date: Mon, 27 Jul 2020 10:32:15 +0200
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

Information forwarded to devuan-bugs@lists.dyne.org, devuan-dev@lists.dyne.org:
bug#498; Package libc6. (Mon, 27 Jul 2020 09:33:02 GMT) (full text, mbox, link).


Message #8 received at 498@bugs.devuan.org (full text, mbox, reply):

From: Mark Hindley <mark@hindley.org.uk>
To: Alessandro Vesely <vesely@tana.it>, 498@bugs.devuan.org
Subject: Re: bug#498: libc6: Permission denied, intermittent in execve
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:
> 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.

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


Merged 497 498 Request was from Mark Hindley <mark@hindley.org.uk> to 498-submit@bugs.devuan.org. (Mon, 27 Jul 2020 09:33:09 GMT) (full text, mbox, link).


Added tag(s) debian. Request was from Mark Hindley <mark@hindley.org.uk> to 498-submit@bugs.devuan.org. (Mon, 27 Jul 2020 09:33:09 GMT) (full text, mbox, link).


Set bug forwarded-to-address to 'https://bugs.debian.org/966343'. Request was from Mark Hindley <mark@hindley.org.uk> to 498-submit@bugs.devuan.org. (Mon, 27 Jul 2020 09:33:09 GMT) (full text, mbox, link).


Marked as found in versions 2.28-10. Request was from Mark Hindley <mark@hindley.org.uk> to control@bugs.devuan.org. (Mon, 27 Jul 2020 09:33:15 GMT) (full text, mbox, link).


Information forwarded to devuan-bugs@lists.dyne.org, devuan-dev@lists.dyne.org:
bug#498; Package libc6. (Mon, 27 Jul 2020 10:03:01 GMT) (full text, mbox, link).


Acknowledgement sent to Alessandro Vesely <vesely@tana.it>:
Extra info received and forwarded to list. Copy sent to devuan-dev@lists.dyne.org. (Mon, 27 Jul 2020 10:03:08 GMT) (full text, mbox, link).


Message #21 received at 498@bugs.devuan.org (full text, mbox, reply):

From: Alessandro Vesely <vesely@tana.it>
To: Mark Hindley <mark@hindley.org.uk>, 498@bugs.devuan.org, 966343@bugs.debian.org
Subject: Re: bug#498: libc6: Permission denied, intermittent in execve
Date: Mon, 27 Jul 2020 11:47:34 +0200
Hi Mark,

On Mon 27/Jul/2020 11:14:01 +0200 Mark Hindley wrote:
> On Mon, Jul 27, 2020 at 10:32:15AM +0200, Alessandro Vesely wrote:
>> Package: libc6
>> Version: GNU C Library (Debian GLIBC 2.28-10) stable release version 2.28.
>> Severity: normal
>> 
>> 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.
> 
> 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?


Bingo!

Jul 27 09:47:25 pcale kernel: [ 1569.887279] audit: type=1400 audit(1595836045.642:33): apparmor="DENIED" operation="exec" profile="thunderbird" name="/opt/lib
reoffice6.4/program/soffice" pid=5402 comm="gio-launch-desk" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

I dunno how come apparmor got installed.  Probably it happened when I upgraded to Beowulf.

After aa-teardown and purging apparmor, execve works as expected.

So this turns out to be a documentation bug.  The execve man page should mention that EACCESS can result as an (unforeseen) apparmor impediment.


Thank you so much
Ale


Information forwarded to devuan-bugs@lists.dyne.org, devuan-dev@lists.dyne.org:
bug#498; Package libc6. (Mon, 27 Jul 2020 10:03:11 GMT) (full text, mbox, link).


Acknowledgement sent to Mark Hindley <mark@hindley.org.uk>:
Extra info received and forwarded to list. Copy sent to devuan-dev@lists.dyne.org. (Mon, 27 Jul 2020 10:03:17 GMT) (full text, mbox, link).


Message #26 received at 498@bugs.devuan.org (full text, mbox, reply):

From: Mark Hindley <mark@hindley.org.uk>
To: Alessandro Vesely <vesely@tana.it>
Cc: 498@bugs.devuan.org, 966343@bugs.debian.org
Subject: Re: bug#498: libc6: Permission denied, intermittent in execve
Date: Mon, 27 Jul 2020 10:53:16 +0100
On Mon, Jul 27, 2020 at 11:47:34AM +0200, Alessandro Vesely wrote:
> > However, one thought that occurs to me is whether apparmor is causing this? Does
> > disabling it[1] restore predictable behaviour?
> 
> Bingo!
> 
> Jul 27 09:47:25 pcale kernel: [ 1569.887279] audit: type=1400 audit(1595836045.642:33): apparmor="DENIED" operation="exec" profile="thunderbird" name="/opt/lib
> reoffice6.4/program/soffice" pid=5402 comm="gio-launch-desk" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
> 
> I dunno how come apparmor got installed.  Probably it happened when I upgraded
> to Beowulf.

Yes, it is now the default in Debian buster and Devuan beowulf has inherited
that.

Mark

Information forwarded to devuan-bugs@lists.dyne.org, devuan-dev@lists.dyne.org:
bug#498; Package libc6. (Mon, 27 Jul 2020 10:33:02 GMT) (full text, mbox, link).


Acknowledgement sent to Samuel Thibault <sthibault@debian.org>:
Extra info received and forwarded to list. Copy sent to devuan-dev@lists.dyne.org. (Mon, 27 Jul 2020 10:33:04 GMT) (full text, mbox, link).


Message #31 received at 498@bugs.devuan.org (full text, mbox, reply):

From: Samuel Thibault <sthibault@debian.org>
To: Alessandro Vesely <vesely@tana.it>, 966343@bugs.debian.org
Cc: Mark Hindley <mark@hindley.org.uk>, 498@bugs.devuan.org
Subject: Re: Bug#966343: bug#498: libc6: Permission denied, intermittent in execve
Date: Mon, 27 Jul 2020 12:13:44 +0200
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...

Samuel

Information forwarded to devuan-bugs@lists.dyne.org, devuan-dev@lists.dyne.org:
bug#498; Package libc6. (Mon, 27 Jul 2020 17:18:01 GMT) (full text, mbox, link).


Acknowledgement sent to Alessandro Vesely <vesely@tana.it>:
Extra info received and forwarded to list. Copy sent to devuan-dev@lists.dyne.org. (Mon, 27 Jul 2020 17:18:09 GMT) (full text, mbox, link).


Message #36 received at 498@bugs.devuan.org (full text, mbox, reply):

From: Alessandro Vesely <vesely@tana.it>
To: 966343@bugs.debian.org
Cc: 498@bugs.devuan.org
Subject: Re: Bug#966343: bug#498: libc6: Permission denied, intermittent in execve
Date: Mon, 27 Jul 2020 19:01:13 +0200
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:


       EACCES The requested access to the file is not allowed, or search permission is denied for one of the directories in the  path
              prefix  of  pathname, or the file did not exist yet and write access to the parent directory is not allowed.  (See also
              path_resolution(7).)

       EACCES Search permission is denied on a component of the path prefix of filename or the name of a  script  interpreter.   (See
              also path_resolution(7).)

       EACCES Write access to the directory containing newpath is denied, or search permission is denied for one of  the  directories
              in the path prefix of oldpath or newpath.  (See also path_resolution(7).)

       EACCES Search permission is denied for a component of the path prefix, or the named file is not writable by  the  user.
              (See also path_resolution(7).)

       EACCES Search permission is denied on a component of the path prefix.  (See also path_resolution(7).)


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.


Best
Ale


Information forwarded to devuan-bugs@lists.dyne.org, devuan-dev@lists.dyne.org:
bug#498; Package libc6. (Tue, 28 Jul 2020 22:33:02 GMT) (full text, mbox, link).


Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to devuan-dev@lists.dyne.org. (Tue, 28 Jul 2020 22:33:05 GMT) (full text, mbox, link).


Message #41 received at 498@bugs.devuan.org (full text, mbox, reply):

From: Aurelien Jarno <aurelien@aurel32.net>
To: Alessandro Vesely <vesely@tana.it>, 966343-done@bugs.debian.org
Cc: 498@bugs.devuan.org
Subject: Re: Bug#966343: bug#498: libc6: Permission denied, intermittent in execve
Date: Wed, 29 Jul 2020 00:14:54 +0200
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

Send a report that this bug log contains spam.


Devuan BTS -- Powered by Debian bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.

Devuan Bugs Owner <owner@bugs.devuan.org>.
Last modified: Wed Sep 30 03:56:56 2020;