From: David Herrmann <dh.herrmann@gmail.com>
To: linux-kernel@vger.kernel.org
Cc: Matthew Wilcox <matthew@wil.cx>, Ryan Lortie <desrt@desrt.ca>,
Hugh Dickins <hughd@google.com>,
Johannes Weiner <hannes@cmpxchg.org>, Kay Sievers <kay@vrfy.org>,
dri-devel@lists.freedesktop.org, Daniel Mack <zonque@gmail.com>,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
Karol Lewandowski <k.lewandowsk@samsung.com>,
Lennart Poettering <lennart@poettering.net>,
Greg Kroah-Hartman <greg@kroah.com>, Tejun Heo <tj@kernel.org>,
"Michael Kerrisk \(man-pages\)" <mtk.manpages@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Alexander Viro <viro@zeniv.linux.org.uk>
Subject: [PATCH man-pages 5/6] fcntl.2: document SHMEM_SET/GET_SEALS commands
Date: Wed, 19 Mar 2014 20:06:50 +0100 [thread overview]
Message-ID: <1395256011-2423-6-git-send-email-dh.herrmann@gmail.com> (raw)
In-Reply-To: <1395256011-2423-1-git-send-email-dh.herrmann@gmail.com>
The SHMEM_GET_SEALS and SHMEM_SET_SEALS commands allow retrieving and
modifying the active set of seals on a file. They're only supported on
selected file-systems (currently shmfs) and are linux-only.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
---
man2/fcntl.2 | 90 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 90 insertions(+)
diff --git a/man2/fcntl.2 b/man2/fcntl.2
index c010a49..53d55a5 100644
--- a/man2/fcntl.2
+++ b/man2/fcntl.2
@@ -57,6 +57,8 @@
.\" Document F_SETOWN_EX and F_GETOWN_EX
.\" 2010-06-17, Michael Kerrisk
.\" Document F_SETPIPE_SZ and F_GETPIPE_SZ.
+.\" 2014-03-19, David Herrmann <dh.herrmann@gmail.com>
+.\" Document SHMEM_SET_SEALS and SHMEM_GET_SEALS
.\"
.TH FCNTL 2 2014-02-20 "Linux" "Linux Programmer's Manual"
.SH NAME
@@ -1064,6 +1066,94 @@ of buffer space currently used to store data produces the error
.BR F_GETPIPE_SZ " (\fIvoid\fP; since Linux 2.6.35)"
Return (as the function result) the capacity of the pipe referred to by
.IR fd .
+.SS File Sealing
+Sealing files limits 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
+.B EPERM
+on this file from now on. The file is said to be sealed. A file does not have
+any seals set by default. Moreover, most filesystems do not support sealing
+(only shmfs implements it right now). The following seals are available:
+.RS
+.TP
+.BR SHMEM_SEAL_SHRINK
+If this seal is set, the file in question cannot be reduced in size. This
+affects
+.BR open (2)
+with the
+.B O_TRUNC
+flag and
+.BR ftruncate (2).
+They will fail with
+.B EPERM
+if you try to shrink the file in question. Increasing the file size is still
+possible.
+.TP
+.BR SHMEM_SEAL_GROW
+If this seal is set, the size of the file in question cannot be increased. This
+affects
+.BR write (2)
+if you write across size boundaries,
+.BR ftruncate (2)
+and
+.BR fallocate (2).
+These calls will fail with
+.B EPERM
+if you use them to increase the file size or write beyond size boundaries. If
+you keep the size or shrink it, those calls still work as expected.
+.TP
+.BR SHMEM_SEAL_WRITE
+If this seal is set, you cannot modify data 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
+.BR write (2)
+and
+.BR fallocate (2)
+(only in combination with the
+.B FALLOC_FL_PUNCH_HOLE
+flag). Those calls will fail with
+.B EPERM
+if this seal is set. Furthermore, trying to create new memory-mappings via
+.BR mmap (2)
+in combination with
+.B MAP_SHARED
+will also fail with
+.BR EPERM .
+.RE
+.TP
+.BR SHMEM_SET_SEALS " (\fIint\fP; since Linux TBD)"
+Change the set of seals of the file referred to by
+.I fd
+to
+.IR arg .
+You are required to own an exclusive reference to the file in question in order
+to modify the seals. Otherwise, this call will fail with
+.BR EPERM .
+There is one exception: If no seals are set, this restriction does not apply and
+you can set seals even if you don't own an exclusive reference. However, in any
+case there may not exist any shared writable mapping or this call will always
+fail with
+.BR EPERM .
+These semantics guarantee that once you verified a specific set of seals is set
+on a given file, nobody besides you (in case you own an exclusive reference) can
+modify the seals, anymore.
+
+You own an exclusive reference to a file if, and only if, the file-descriptor
+passed to
+.BR fcntl (2)
+is the only reference to the underlying inode. There must not be any duplicates
+of this file-descriptor, no other open files to the same underlying inode, no
+hard-links or any active memory mappings.
+.TP
+.BR SHMEM_GET_SEALS " (\fIvoid\fP; since Linux TBD)"
+Return (as the function result) the current set of seals of the file referred to
+by
+.IR fd .
+If no seals are set, 0 is returned. If the file does not support sealing, -1 is
+returned and
+.I errno
+is set to
+.BR EINVAL .
.SH RETURN VALUE
For a successful call, the return value depends on the operation:
.TP 0.9i
--
1.9.0
next prev parent reply other threads:[~2014-03-19 19:06 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-19 19:06 [PATCH 0/6] File Sealing & memfd_create() David Herrmann
2014-03-19 19:06 ` [PATCH 1/6] fs: fix i_writecount on shmem and friends David Herrmann
2014-03-19 19:06 ` [PATCH 2/6] shm: add sealing API David Herrmann
2014-03-19 19:06 ` [PATCH 3/6] shm: add memfd_create() syscall David Herrmann
2014-03-20 8:47 ` Cyrill Gorcunov
2014-03-20 9:01 ` Pavel Emelyanov
2014-03-20 11:29 ` David Herrmann
2014-03-20 11:50 ` Pavel Emelyanov
2014-03-20 19:22 ` John Stultz
2014-04-02 13:38 ` Konstantin Khlebnikov
2014-04-02 14:18 ` David Herrmann
2014-04-02 14:52 ` Konstantin Khlebnikov
2014-04-10 19:07 ` Andy Lutomirski
2014-03-19 19:06 ` [PATCH 4/6] selftests: add memfd_create() + sealing tests David Herrmann
2014-03-19 19:06 ` David Herrmann [this message]
2014-03-19 19:06 ` [PATCH man-pages 6/6] memfd_create.2: add memfd_create() man-page David Herrmann
2014-03-20 2:55 ` [PATCH 0/6] File Sealing & memfd_create() Greg Kroah-Hartman
2014-03-20 3:49 ` Linus Torvalds
2014-03-20 8:07 ` David Herrmann
2014-03-20 14:41 ` One Thousand Gnomes
2014-03-20 15:12 ` David Herrmann
2014-03-20 15:26 ` One Thousand Gnomes
2014-03-20 15:32 ` tytso
2014-03-20 15:39 ` One Thousand Gnomes
2014-03-20 15:48 ` David Herrmann
2014-03-20 16:38 ` tytso
2014-04-10 19:14 ` Andy Lutomirski
2014-04-10 20:32 ` Theodore Ts'o
2014-04-10 20:37 ` Andy Lutomirski
2014-04-10 20:49 ` David Herrmann
2014-04-10 21:16 ` Andy Lutomirski
2014-04-10 22:57 ` David Herrmann
2014-04-10 23:05 ` Andy Lutomirski
2014-04-10 23:16 ` David Herrmann
2014-04-10 23:32 ` Andy Lutomirski
2014-04-20 15:03 ` Pavel Machek
2014-06-17 9:48 ` Florian Weimer
2014-06-17 16:21 ` Andy Lutomirski
2014-04-10 14:45 ` Colin Walters
2014-04-10 19:15 ` Andy Lutomirski
2014-04-10 19:45 ` Colin Walters
2014-04-11 6:09 ` Alex Elsayed
2014-04-08 13:00 ` Florian Weimer
2014-04-09 21:31 ` David Herrmann
2014-04-22 9:10 ` Florian Weimer
2014-04-22 11:55 ` David Herrmann
2014-04-22 12:44 ` Florian Weimer
2014-04-22 12:55 ` David Herrmann
2014-04-10 19:17 ` Andy Lutomirski
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=1395256011-2423-6-git-send-email-dh.herrmann@gmail.com \
--to=dh.herrmann@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=desrt@desrt.ca \
--cc=dri-devel@lists.freedesktop.org \
--cc=greg@kroah.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=k.lewandowsk@samsung.com \
--cc=kay@vrfy.org \
--cc=lennart@poettering.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew@wil.cx \
--cc=mtk.manpages@gmail.com \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=zonque@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;
as well as URLs for NNTP newsgroup(s).