fcntl.2: document F_GET_SEALS on tmpfs peculiarity
PATCH 1/1 fcntl.2: document F_GET_SEALS on tmpfs peculiarity
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
--- man2/fcntl.2 | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-)
man2/fcntl.2 +15 -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
Signature · 1 line
2.33.1
Adding the maintainers of mm/{shmem,memfd}.c and fs/hugetlbfs/ just in case this was not intended behaviour.
Quoted 56 lines · Kir Kolyshkin
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_SEALSreturns 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 <[email protected]>Cc David Herrmann <[email protected]>Signed-off-by Kir Kolyshkin <[email protected]>--- man2/fcntl.2 | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-)man2/fcntl.2 +15
-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 shareSignature · 1 line
2.33.1
Signature · 4 lines
Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>
Hugh Dickins
Acked-byQuoted 2 lines · Aleksa Sarai
Adding the maintainers of
mm/{shmem,memfd}.candfs/hugetlbfs/just in case this was not intended behaviour.
Kir is correct - thanks - and it is intended behaviour. Not consciously intended to make for a difficult manpage, but the implementation was intended to be simple, so tmpfs and hugetlbfs do not internally distinguish memfd objects from filesystem files - their filesystem files simply start off with F_SEAL_SEAL to rule out any sealing.
Quoted 13 lines · Kir Kolyshkin
Quoted 11 lines
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_SEALSreturns 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).
Quoted 8 lines
Quoted 8 lines
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 <[email protected]>Cc David Herrmann <[email protected]>Signed-off-by Kir Kolyshkin <[email protected]>
Quoted 43 lines
Quoted 37 lines
--- man2/fcntl.2 | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-)man2/fcntl.2 +15
-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 shareSignature · 1 line
2.33.1Signature · 4 lines
Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>
Mike Kravetz
Acked-byQuoted 11 lines · Hugh Dickins
Quoted 2 lines · Aleksa Sarai
Adding the maintainers of
mm/{shmem,memfd}.candfs/hugetlbfs/just in case this was not intended behaviour.Kir is correct - thanks - and it is intended behaviour. Not consciously intended to make for a difficult manpage, but the implementation was intended to be simple, so tmpfs and hugetlbfs do not internally distinguish memfd objects from filesystem files - their filesystem files simply start off with
F_SEAL_SEALto rule out any sealing.
Thanks Hugh, I agree.
Quoted 15 lines
Quoted 15 lines · Kir Kolyshkin
Quoted 14 lines
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_SEALSreturns 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).
Quoted 7 lines
Quoted 5 lines
Quoted 5 lines
[1] https://github.com/opencontainers/runc/pull/3342
Cc Aleksa Sarai <[email protected]>Cc David Herrmann <[email protected]>Signed-off-by Kir Kolyshkin <[email protected]>Acked-by Hugh Dickins <[email protected]>
Signature · 1 line
Mike Kravetz