From unknown Fri Mar 29 00:40:52 2024 X-Loop: owner@bugs.devuan.org Subject: bug#498: Bug#966343: bug#498: libc6: Permission denied, intermittent in execve Reply-To: Aurelien Jarno , 498@bugs.devuan.org Resent-From: Aurelien Jarno Resent-To: devuan-bugs@lists.dyne.org Resent-CC: devuan-dev@lists.dyne.org X-Loop: owner@bugs.devuan.org Resent-Date: Tue, 28 Jul 2020 22:33:02 +0000 Resent-Message-ID: Resent-Sender: owner@bugs.devuan.org X-Devuan-PR-Message: followup 498 X-Devuan-PR-Package: libc6 X-Devuan-PR-Keywords: debian References: <159583832778.5523.4267786497736057480.reportbug@pcale.tana> <4c3f732a-b026-a7a6-bea5-c49fff74267a@tana.it> <20200727091401.GQ3011@hindley.org.uk> <4c3f732a-b026-a7a6-bea5-c49fff74267a@tana.it> <1a948266-b3c2-e3c6-6f91-fda019203850@tana.it> <20200727101344.wovj4a2l4g4xb2hk@function> <20200727101344.wovj4a2l4g4xb2hk@function> <4c3f732a-b026-a7a6-bea5-c49fff74267a@tana.it> <15a0722b-ed58-a804-7d66-12ab5693329e@tana.it> <4c3f732a-b026-a7a6-bea5-c49fff74267a@tana.it> Received: via spool by 498-submit@bugs.devuan.org id=B498.15959748016097 (code B ref 498); Tue, 28 Jul 2020 22:33:02 +0000 Received: (at 498) by bugs.devuan.org; 28 Jul 2020 22:20:01 +0000 Delivered-To: devuanbugs@dyne.org Received: from tupac3.dyne.org [195.169.149.119] by doc.devuan.org with IMAP (fetchmail-6.4.0.beta4) for (single-drop); Tue, 28 Jul 2020 22:20:01 +0000 (UTC) Received: from hall.aurel32.net (hall.aurel32.net [195.154.113.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by vm6.ganeti.dyne.org (Postfix) with ESMTPS id E3FEEF608DA for <498@bugs.devuan.org>; Wed, 29 Jul 2020 00:14:59 +0200 (CEST) Authentication-Results: vm6.ganeti.dyne.org; dkim=pass (2048-bit key; secure) header.d=aurel32.net header.i=@aurel32.net header.b="RzTXUsbY"; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=aurel32.net ; s=202004.hall; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Content-Transfer-Encoding:From:Reply-To: Subject:Content-ID:Content-Description:X-Debbugs-Cc; bh=7Ksfl4NFsU2PVvrTieylN3C1A8tB6Y4MzI+HHhAGCVM=; b=RzTXUsbYTW6aIA37CKsfnDrhTI 3wtLyT0rRx6GD+uLIH7Eeh5/ZuVxVEh7eV9sQ7lSpz+EcfB8b5wkiCrGySQ5/yubvJWe7TCMVhp8B 2PqJxYSJCo+qSBYgfWCF//Jgi46uEXZXFGdIB6RmS+qNhvoIrxiIFqk+o8lwkenne7AUqC3zRJBlG wG+ssVBfztaNes5My7P2v5HComNyKkZ65FBuFSLXh2Ygz3NCFRxee4jOcwMd7vEcsKd93v4AOyfWc Hd8LfTnfLXNQxOzDo+KyqR1blN1b/DUaJeqMHILqeehVX4C3h6qLd6jUldgCFL28IEMfMk5tuvEtu Ee4BeBPg==; Received: from ohm.aurel32.net ([2001:bc8:30d7:111::1000]) by hall.aurel32.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k0Xs9-0003eu-EP; Wed, 29 Jul 2020 00:14:57 +0200 Received: from aurel32 by ohm.aurel32.net with local (Exim 4.94) (envelope-from ) id 1k0Xs6-0028Fv-Kv; Wed, 29 Jul 2020 00:14:54 +0200 Date: Wed, 29 Jul 2020 00:14:54 +0200 From: Aurelien Jarno To: Alessandro Vesely , 966343-done@bugs.debian.org Cc: 498@bugs.devuan.org Message-ID: <20200728221454.GJ8215@aurel32.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15a0722b-ed58-a804-7d66-12ab5693329e@tana.it> User-Agent: Mutt/1.14.0 (2020-05-02) X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS autolearn=disabled version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tupac3.dyne.org Hi, On 2020-07-27 19:01, Alessandro Vesely wrote: > On Mon, 27 Jul 2020 12:13:44 +0200 Samuel Thibault 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