NAME |LIBRARY |SYNOPSIS |DESCRIPTION |RETURN VALUE |ERRORS |STANDARDS |HISTORY |SEE ALSO |COLOPHON | |
F_GET_SEALS(2const)F_GET_SEALS(2const)F_GET_SEALS, F_ADD_SEALS - get/add file seals
Standard C library (libc,-lc)
#include <fcntl.h>int fcntl(intfd, F_ADD_SEALS, intarg);int fcntl(intfd, F_GET_SEALS);
File seals limit the set of allowed operations on a given file. For each seal that is set on a file, a specific set of operations will fail withEPERMon this file from now on. The file is said to be sealed. The default set of seals depends on the type of the underlying file and filesystem. For an overview of file sealing, a discussion of its purpose, and some code examples, seememfd_create(2). Currently, file seals can be applied only to a file descriptor returned bymemfd_create(2) (if theMFD_ALLOW_SEALINGwas employed). On other filesystems, allfcntl() operations that operate on seals will returnEINVAL. Seals are a property of an inode. Thus, all open file descriptors referring to the same inode share the same set of seals. Furthermore, seals can never be removed, only added.F_ADD_SEALS Add the seals given in the bit-mask argumentarg to the set of seals of the inode referred to by the file descriptorfd. Seals cannot be removed again. Once this call succeeds, the seals are enforced by the kernel immediately. If the current set of seals includesF_SEAL_SEAL(see below), then this call will be rejected withEPERM. Adding a seal that is already set is a no-op, in caseF_SEAL_SEAL is not set already. In order to place a seal, the file descriptorfd must be writable.F_GET_SEALS Return (as the function result) the current set of seals of the inode referred to byfd. If no seals are set, 0 is returned. If the file does not support sealing, -1 is returned anderrno is set toEINVAL. The following seals are available:F_SEAL_SEAL If this seal is set, any further call tofcntl() withF_ADD_SEALSfails with the errorEPERM. Therefore, this seal prevents any modifications to the set of seals itself. If the initial set of seals of a file includesF_SEAL_SEAL, then this effectively causes the set of seals to be constant and locked.F_SEAL_SHRINK If this seal is set, the file in question cannot be reduced in size. This affectsopen(2) with theO_TRUNCflag as well astruncate(2) andftruncate(2). Those calls fail withEPERMif you try to shrink the file in question. Increasing the file size is still possible.F_SEAL_GROW If this seal is set, the size of the file in question cannot be increased. This affectswrite(2) beyond the end of the file,truncate(2),ftruncate(2), andfallocate(2). These calls fail withEPERMif you use them to increase the file size. If you keep the size or shrink it, those calls still work as expected.F_SEAL_WRITE If this seal is set, you cannot modify the contents of the file. Note that shrinking or growing the size of the file is still possible and allowed. Thus, this seal is normally used in combination with one of the other seals. This seal affectswrite(2) andfallocate(2) (only in combination with theFALLOC_FL_PUNCH_HOLEflag). Those calls fail withEPERMif this seal is set. Furthermore, trying to create new shared, writable memory-mappings viammap(2) will also fail withEPERM. Using theF_ADD_SEALSoperation to set theF_SEAL_WRITE seal fails withEBUSYif any writable, shared mapping exists. Such mappings must be unmapped before you can add this seal. Furthermore, if there are any asynchronous I/O operations (io_submit(2)) pending on the file, all outstanding writes will be discarded.F_SEAL_FUTURE_WRITE(since Linux 5.1) The effect of this seal is similar toF_SEAL_WRITE, but the contents of the file can still be modified via shared writable mappings that were created prior to the seal being set. Any attempt to create a new writable mapping on the file viammap(2) will fail withEPERM. Likewise, an attempt to write to the file viawrite(2) will fail withEPERM. Using this seal, one process can create a memory buffer that it can continue to modify while sharing that buffer on a "read-only" basis with other processes.
F_GET_SEALS A bit mask identifying the seals that have been set for the inode referred to byfd.F_ADD_SEALS Zero. On error, -1 is returned, anderrno is set to indicate the error.
Seefcntl(2).EBUSYop isF_ADD_SEALS,arg includesF_SEAL_WRITE, and there exists a writable, shared mapping on the file referred to byfd.EINVALop isF_ADD_SEALSandarg includes an unrecognized sealing bit.EINVALThe filesystem containing the inode referred to byfd does not support sealing.EPERMop wasF_ADD_SEALS, butfd was not open for writing or the current set of seals on the file already includesF_SEAL_SEAL.
Linux.
Linux 3.17.
fcntl(2)
This page is part of theman-pages (Linux kernel and C library user-space interface documentation) project. Information about the project can be found at ⟨https://www.kernel.org/doc/man-pages/⟩. If you have a bug report for this manual page, see ⟨https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING⟩. This page was obtained from the tarball man-pages-6.15.tar.gz fetched from ⟨https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/⟩ on 2025-08-11. If you discover any rendering problems in this HTML version of the page, or you believe there is a better or more up- to-date source for the page, or you have corrections or improvements to the information in this COLOPHON (which isnot part of the original manual page), send a mail to man-pages@man7.orgLinux man-pages 6.15 2025-07-20F_GET_SEALS(2const)Pages that refer to this page:fcntl(2)
HTML rendering created 2025-09-06 byMichael Kerrisk, author ofThe Linux Programming Interface. For details of in-depthLinux/UNIX system programming training courses that I teach, lookhere. Hosting byjambit GmbH. | ![]() |