linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Günther Noack" <gnoack3000@gmail.com>
To: "Mickaël Salaün" <mic@digikod.net>
Cc: "Günther Noack" <gnoack@google.com>,
	linux-security-module@vger.kernel.org,
	"Jeff Xu" <jeffxu@google.com>, "Arnd Bergmann" <arnd@arndb.de>,
	"Christian Brauner" <brauner@kernel.org>,
	"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, "Michael Kerrisk" <mtk@man7.org>
Subject: Re: [PATCH v9 1/8] landlock: Add IOCTL access right
Date: Sun, 18 Feb 2024 09:34:39 +0100	[thread overview]
Message-ID: <20240218.a01103783ca4@gnoack.org> (raw)
In-Reply-To: <20240216.phai5oova1Oa@digikod.net>

On Fri, Feb 16, 2024 at 04:51:40PM +0100, Mickaël Salaün wrote:
> On Fri, Feb 16, 2024 at 03:11:18PM +0100, Mickaël Salaün wrote:
> > What about /proc/*/fd/* ? We can test with open_proc_fd() to make sure
> > our assumptions are correct.
> 
> Actually, these fifo and socket checks (and related optimizations)
> should already be handled with is_nouser_or_private() called by
> is_access_to_paths_allowed(). Some new dedicated tests should help
> though.

I am generally a bit confused about how opening /proc/*/fd/* works.

Specifically:

* Do we have to worry about the scenario where the file_open hook gets
  called with the same struct file* twice (overwriting the access
  rights)?

* I had trouble finding the place in fs/proc/ where the re-opening is
  implemented.

Do you happen to understand this in more detail?  At what point do the
re-opened files start sharing the same kernel objects?  Is that at the
inode level?

The documentation I consulted unfortunately did not explain it either:

* The man page (proc_pid_fd(5), or previously proc(5)) does not
  discuss the behavior on open() much, apart from using it in some
  examples.

* Michael Kerrisk's "Linux Programming Interface" book claims that the
  behaviour of opening /dev/fd/1 is like doing dup(1) (section 5.11)
  -- that is true on other UNIXes, but on Linux the resulting file
  descriptors do not share the same struct file* apparently.  This
  makes a difference for regular files, where the two FDs subsequently
  use two separate offsets into the file (f_pos).

Thanks,
–Günther

  reply	other threads:[~2024-02-18  8:34 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-09 17:06 [PATCH v9 0/8] Landlock: IOCTL support Günther Noack
2024-02-09 17:06 ` [PATCH v9 1/8] landlock: Add IOCTL access right Günther Noack
2024-02-10 11:06   ` Günther Noack
2024-02-10 11:49     ` Arnd Bergmann
2024-02-12 11:09       ` Christian Brauner
2024-02-12 22:10         ` Günther Noack
2024-02-10 11:18   ` Günther Noack
2024-02-16 14:11     ` Mickaël Salaün
2024-02-16 15:51       ` Mickaël Salaün
2024-02-18  8:34         ` Günther Noack [this message]
2024-02-19 21:44           ` Günther Noack
2024-02-16 17:19   ` Mickaël Salaün
2024-02-19 18:34   ` Mickaël Salaün
2024-02-19 18:35     ` [RFC PATCH] fs: Add vfs_masks_device_ioctl*() helpers Mickaël Salaün
2024-03-01 13:42       ` Mickaël Salaün
2024-03-01 16:24       ` Arnd Bergmann
2024-03-01 18:35         ` Mickaël Salaün
2024-03-05 18:13       ` Günther Noack
2024-03-06 13:47         ` Mickaël Salaün
2024-03-06 15:18           ` Arnd Bergmann
2024-03-07 12:15             ` Christian Brauner
2024-03-07 12:21               ` Arnd Bergmann
2024-03-07 12:57                 ` Günther Noack
2024-03-07 20:40                   ` Paul Moore
2024-03-07 23:09                     ` Dave Chinner
2024-03-07 23:35                       ` Paul Moore
2024-03-08  7:02                       ` Arnd Bergmann
2024-03-08  9:29                         ` Mickaël Salaün
2024-03-08 19:22                           ` Paul Moore
2024-03-08 20:12                             ` Mickaël Salaün
2024-03-08 22:04                               ` Casey Schaufler
2024-03-08 22:25                               ` Paul Moore
2024-03-09  8:14                                 ` Günther Noack
2024-03-09 17:41                                   ` Casey Schaufler
2024-03-11 19:04                                   ` Paul Moore
2024-03-08 11:03                         ` Günther Noack
2024-03-11  1:03                           ` Dave Chinner
2024-03-11  9:01                             ` Günther Noack
2024-03-11 22:12                               ` Dave Chinner
2024-03-12 10:58                                 ` Mickaël Salaün
2024-02-28 12:57     ` [PATCH v9 1/8] landlock: Add IOCTL access right Günther Noack
2024-03-01 12:59       ` Mickaël Salaün
2024-03-01 13:38         ` Mickaël Salaün
2024-02-09 17:06 ` [PATCH v9 2/8] selftests/landlock: Test IOCTL support Günther Noack
2024-02-09 17:06 ` [PATCH v9 3/8] selftests/landlock: Test IOCTL with memfds Günther Noack
2024-02-09 17:06 ` [PATCH v9 4/8] selftests/landlock: Test ioctl(2) and ftruncate(2) with open(O_PATH) Günther Noack
2024-02-09 17:06 ` [PATCH v9 5/8] selftests/landlock: Test IOCTLs on named pipes Günther Noack
2024-02-09 17:06 ` [PATCH v9 6/8] selftests/landlock: Check IOCTL restrictions for named UNIX domain sockets Günther Noack
2024-02-09 17:06 ` [PATCH v9 7/8] samples/landlock: Add support for LANDLOCK_ACCESS_FS_IOCTL Günther Noack
2024-02-09 17:06 ` [PATCH v9 8/8] landlock: Document IOCTL support 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=20240218.a01103783ca4@gnoack.org \
    --to=gnoack3000@gmail.com \
    --cc=allenwebb@google.com \
    --cc=arnd@arndb.de \
    --cc=brauner@kernel.org \
    --cc=dtor@google.com \
    --cc=gnoack@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=mtk@man7.org \
    --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 NNTP newsgroup(s).