summaryrefslogtreecommitdiff
tag nameimmutable-files_2019-06-28 (774f3ac0862c0e06f456d1b1f6a143342933ebbd)
tag date2019-06-28 10:57:56 -0700
tagged byDarrick J. Wong <darrick.wong@oracle.com>
tagged objectcommit 8be6f7aad1...
vfs: make immutable files actually immutable
The chattr(1) manpage has this to say about the immutable bit that system administrators can set on files: "A file with the 'i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file, most of the file's metadata can not be modified, and the file can not be opened in write mode." Given the clause about how the file 'cannot be modified', it is surprising that programs holding writable file descriptors can continue to write to and truncate files after the immutable flag has been set, but they cannot call other things such as utimes, fallocate, unlink, link, setxattr, or reflink. Since the immutable flag is only settable by administrators, resolve this inconsistent behavior in favor of the documented behavior -- once the flag is set, the file cannot be modified, period. We presume that administrators must be trusted to know what they're doing, and that cutting off programs with writable fds will probably break them. Therefore, add immutability checks to the relevant VFS functions, then refactor the SETFLAGS and FSSETXATTR implementations to use common argument checking functions so that we can then force pagefaults on all the file data when setting immutability. Note that various distro manpages points out the inconsistent behavior of the various Linux filesystems w.r.t. immutable. This fixes all that. I also discovered that userspace programs can write and create writable memory mappings to active swap files. This is extremely bad because this allows anyone with write privileges to corrupt system memory. The final patch in this series closes off that hole, at least for swap files.