Linux-Security-Module Archive mirror
 help / color / mirror / Atom feed
From: "Günther Noack" <gnoack@google.com>
To: "Mickaël Salaün" <mic@digikod.net>
Cc: linux-security-module@vger.kernel.org,
	Jeff Xu <jeffxu@google.com>,  Arnd Bergmann <arnd@arndb.de>,
	Jorge Lucangeli Obes <jorgelo@chromium.org>,
	Allen Webb <allenwebb@google.com>,
	 Dmitry Torokhov <dtor@google.com>,
	Paul Moore <paul@paul-moore.com>,
	 Konstantin Meskhidze <konstantin.meskhidze@huawei.com>,
	Matt Bobrowski <repnop@google.com>,
	 linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v14 08/12] selftests/landlock: Exhaustive test for the IOCTL allow-list
Date: Fri, 19 Apr 2024 16:49:58 +0200	[thread overview]
Message-ID: <ZiKElubaXYAsYq4q@google.com> (raw)
In-Reply-To: <20240418.dezuw1Ohg0ca@digikod.net>

On Thu, Apr 18, 2024 at 10:44:43PM -0700, Mickaël Salaün wrote:
> On Thu, Apr 18, 2024 at 02:21:49PM +0200, Günther Noack wrote:
> > I spotted an additional problem with FICLONERANGE -- when we pass a
> > zero-initialized buffer to that IOCTL, it'll interpret some of these zeros
> > to refer to file descriptor 0 (stdin)... and what that means is not
> > controlled by the test - the error code can change depending on what that
> > FD is.  (I don't want to start filling in all these structs individually.)
> 
> I'm OK with your approach as long as the tests are deterministic,
> whatever FD 0 is (or not), and as long at they don't have an impact on
> FD 0.  To make it more generic and to avoid side effects, I think we
> should (always) close FD 0 in ioctl_error() (and explain the reason).

Done, good idea.

—Günther

  reply	other threads:[~2024-04-19 14:50 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-05 21:40 [PATCH v14 00/12] Landlock: IOCTL support Günther Noack
2024-04-05 21:40 ` [PATCH v14 01/12] fs: Return ENOTTY directly if FS_IOC_GETUUID or FS_IOC_GETFSSYSFSPATH fail Günther Noack
2024-04-05 21:54   ` Kent Overstreet
2024-04-09 10:08   ` (subset) " Christian Brauner
2024-04-09 12:11     ` Mickaël Salaün
2024-04-12 15:17   ` Mickaël Salaün
2024-04-05 21:40 ` [PATCH v14 02/12] landlock: Add IOCTL access right for character and block devices Günther Noack
2024-04-12 15:16   ` Mickaël Salaün
2024-04-18  9:28     ` Günther Noack
2024-04-19  5:43       ` Mickaël Salaün
2024-04-05 21:40 ` [PATCH v14 03/12] selftests/landlock: Test IOCTL support Günther Noack
2024-04-12 15:17   ` Mickaël Salaün
2024-04-18 11:10     ` Günther Noack
2024-04-19  5:44   ` Mickaël Salaün
2024-04-19 14:06     ` Günther Noack
2024-04-05 21:40 ` [PATCH v14 04/12] selftests/landlock: Test IOCTL with memfds Günther Noack
2024-04-05 21:40 ` [PATCH v14 05/12] selftests/landlock: Test ioctl(2) and ftruncate(2) with open(O_PATH) Günther Noack
2024-04-05 21:40 ` [PATCH v14 06/12] selftests/landlock: Test IOCTLs on named pipes Günther Noack
2024-04-05 21:40 ` [PATCH v14 07/12] selftests/landlock: Check IOCTL restrictions for named UNIX domain sockets Günther Noack
2024-04-12 15:17   ` Mickaël Salaün
2024-04-18 11:24     ` Günther Noack
2024-04-05 21:40 ` [PATCH v14 08/12] selftests/landlock: Exhaustive test for the IOCTL allow-list Günther Noack
2024-04-12 15:18   ` Mickaël Salaün
2024-04-18 12:21     ` Günther Noack
2024-04-19  5:44       ` Mickaël Salaün
2024-04-19 14:49         ` Günther Noack [this message]
2024-04-05 21:40 ` [PATCH v14 09/12] samples/landlock: Add support for LANDLOCK_ACCESS_FS_IOCTL_DEV Günther Noack
2024-04-05 21:40 ` [PATCH v14 10/12] landlock: Document IOCTL support Günther Noack
2024-04-05 21:40 ` [PATCH v14 11/12] MAINTAINERS: Notify Landlock maintainers about changes to fs/ioctl.c Günther Noack
2024-04-05 21:40 ` [PATCH v14 12/12] fs/ioctl: Add a comment to keep the logic in sync with LSM policies Günther Noack

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZiKElubaXYAsYq4q@google.com \
    --to=gnoack@google.com \
    --cc=allenwebb@google.com \
    --cc=arnd@arndb.de \
    --cc=dtor@google.com \
    --cc=jeffxu@google.com \
    --cc=jorgelo@chromium.org \
    --cc=konstantin.meskhidze@huawei.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mic@digikod.net \
    --cc=paul@paul-moore.com \
    --cc=repnop@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).