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@xxxxxxxxxx> Cc: David Herrmann <dh.herrmann@xxxxxxxxx> Signed-off-by: Kir Kolyshkin <kolyshkin@xxxxxxxxx> --- 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
