Provided by: manpages-dev_6.16-1_all bug

NAME

       F_GET_SEALS, F_ADD_SEALS - get/add file seals

LIBRARY

       Standard C library (libc, -lc)

SYNOPSIS

       #include <fcntl.h>

       int fcntl(int fd, F_ADD_SEALS, int arg);
       int fcntl(int fd, F_GET_SEALS);

DESCRIPTION

       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 with EPERM on 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, see memfd_create(2).

       Currently,  file  seals  can  be  applied  only  to a file descriptor returned by memfd_create(2) (if the
       MFD_ALLOW_SEALING was employed).  On other filesystems, all fcntl() operations that operate on seals will
       return EINVAL.

       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 argument arg to the set of seals of the inode referred to by
              the file descriptor fd.  Seals cannot be removed again.  Once this call succeeds,  the  seals  are
              enforced by the kernel immediately.  If the current set of seals includes F_SEAL_SEAL (see below),
              then this call will be rejected with EPERM.  Adding a seal that is already set is a no-op, in case
              F_SEAL_SEAL  is  not  set  already.   In  order  to  place  a seal, the file descriptor fd must be
              writable.

       F_GET_SEALS
              Return (as the function result) the current set of seals of the inode referred to by  fd.   If  no
              seals  are  set, 0 is returned.  If the file does not support sealing, -1 is returned and errno is
              set to EINVAL.

       The following seals are available:

       F_SEAL_SEAL
              If this seal is set, any further call to fcntl() with F_ADD_SEALS  fails  with  the  error  EPERM.
              Therefore, this seal prevents any modifications to the set of seals itself.  If the initial set of
              seals of a file includes F_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 affects open(2) with
              the O_TRUNC flag as well as truncate(2) and ftruncate(2).  Those calls fail with EPERM if 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 affects write(2)
              beyond the end of the file, truncate(2), ftruncate(2), and fallocate(2).  These  calls  fail  with
              EPERM  if  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 affects write(2)  and  fallocate(2)  (only  in
              combination with the FALLOC_FL_PUNCH_HOLE flag).  Those calls fail with EPERM if this seal is set.
              Furthermore, trying to create new shared, writable memory-mappings via mmap(2) will also fail with
              EPERM.

              Using  the  F_ADD_SEALS  operation  to set the F_SEAL_WRITE seal fails with EBUSY if 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 to F_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 via mmap(2) will fail with EPERM.  Likewise, an
              attempt to write to the file via write(2) will fail with EPERM.

              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.

RETURN VALUE

       F_GET_SEALS
              A bit mask identifying the seals that have been set for the inode referred to by fd.

       F_ADD_SEALS
              Zero.

       On error, -1 is returned, and errno is set to indicate the error.

ERRORS

       See fcntl(2).

       EBUSY  op  is  F_ADD_SEALS, arg includes F_SEAL_WRITE, and there exists a writable, shared mapping on the
              file referred to by fd.

       EINVAL op is F_ADD_SEALS and arg includes an unrecognized sealing bit.

       EINVAL The filesystem containing the inode referred to by fd does not support sealing.

       EPERM  op was F_ADD_SEALS, but fd was not open for writing or the  current  set  of  seals  on  the  file
              already includes F_SEAL_SEAL.

STANDARDS

       Linux.

HISTORY

       Linux 3.17.

SEE ALSO

       fcntl(2)

Linux man-pages 6.16                               2025-07-20                                F_GET_SEALS(2const)