public inbox for linux-man@vger.kernel.org
 help / color / mirror / Atom feed
From: Kir Kolyshkin <kolyshkin@gmail.com>
To: linux-man@vger.kernel.org
Cc: Michael Kerrisk <mtk.manpages@gmail.com>,
	Kir Kolyshkin <kolyshkin@gmail.com>,
	Aleksa Sarai <cyphar@cyphar.com>,
	David Herrmann <dh.herrmann@gmail.com>
Subject: [PATCH] fcntl.2: document F_GET_SEALS on tmpfs peculiarity
Date: Fri, 21 Jan 2022 16:52:51 -0800	[thread overview]
Message-ID: <20220122005251.1441343-1-kolyshkin@gmail.com> (raw)

Currently, from the description of file sealing it can be deduced that
unless the fd is a memfd, all sealing operations fail with EINVAL.

Apparently, it's not true for tmpfs or hugetlbfs -- F_GET_SEALS returns
1 (F_SEAL_SEAL) for an fd opened on these filesystems (probably because
those are used to back memfd files).

Fix the description to mention that peculiarity. Not knowing this can
result in incorrect code logic (see [1], where the code mistook a
descriptor of a file opened on on tmpfs for a memfd).

While at it, clarify that fcntl does not actually return EINVAL, but
sets errno to it (as it is usually said elsewhere).

[1] https://github.com/opencontainers/runc/pull/3342

Cc: Aleksa Sarai <cyphar@cyphar.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
---
 man2/fcntl.2 | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/man2/fcntl.2 b/man2/fcntl.2
index 7b5604e3a..f951b05ff 100644
--- a/man2/fcntl.2
+++ b/man2/fcntl.2
@@ -1402,10 +1402,23 @@ file seals can be applied only to a file descriptor returned by
 (if the
 .B MFD_ALLOW_SEALING
 was employed).
-On other filesystems, all
+On all other filesystems, except
+.BR tmpfs (5)
+and
+.BR hugetlbfs ,
+all
 .BR fcntl ()
-operations that operate on seals will return
+operations that operate on seals will fail with
+.I errno
+set to
 .BR EINVAL .
+For a descriptor from a file on
+.BR tmpfs (5)
+or
+.BR hugetlbfs ,
+.B F_GET_SEALS
+returns
+.BR F_SEAL_SEAL .
 .PP
 Seals are a property of an inode.
 Thus, all open file descriptors referring to the same inode share
-- 
2.33.1


             reply	other threads:[~2022-01-22  0:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-22  0:52 Kir Kolyshkin [this message]
2022-01-22  9:04 ` [PATCH] fcntl.2: document F_GET_SEALS on tmpfs peculiarity Aleksa Sarai
2022-01-24  4:18   ` Hugh Dickins
2022-01-24 18:35     ` Mike Kravetz

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=20220122005251.1441343-1-kolyshkin@gmail.com \
    --to=kolyshkin@gmail.com \
    --cc=cyphar@cyphar.com \
    --cc=dh.herrmann@gmail.com \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.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