On Sat, Jul 29, 2017, at 03:43 PM, Dan Williams wrote: > An inode with this flag set indicates that the file's block map cannot > be changed, no size change, deletion, hole-punch, range collapse, or > reflink. > > The implementation of toggling the flag and sealing the state of the > extent map is saved for a later patch. The functionality provided by > S_IOMAP_IMMUTABLE, once toggle support is added, will be a superset of > that provided by S_SWAPFILE, and it is targeted to replace it. > > For now, only xfs and the core vfs are updated to consider the new flag. Quite a while ago I started a request for O_OBJECT: http://www.spinics.net/lists/linux-fsdevel/msg75085.html A few months ago I was thinking about that more and realized it'd likely be more palatable to land as an inode flag, like you're doing here. Now, S_IOMAP_IMMUTABLE would be quite close to the semantics I want for ostree, except we also want to disallow changes to the inode uid, gid or mode. (Extended attributes are a whole other story; but I'd like to at least disallow changes to the security. namespace). The goal here is mostly about resilience to *accidental* changes; think an admin doing `cp /path/to/binary /usr/bin/bash` which does open(O_TRUNC), which would hence corrupt all hardlinks. S_IOMAP_IMMUTABLE would give a lot of great protection against those types of accidental changes - most of them are either going to be open(O_TRUNC) or O_APPEND. Since you're touching various write paths here, perhaps we can also add S_CONTENTS_IMMUTABLE or something at the same time? If this lands as is - I'm quite likely to change ostree to use it; any objections to that? As mentioned in the thread, there are several other cases of "content immutable" files in userspace, such as QEMU "qcow2", git objects. And really the most classic example is /etc/sudoers and the need for a special "visudo" program to really ensure that editors don't do in-place overwrites. But it'd be great if we can use this push to also land "content immutabilty" or however we decide to call it. -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
