Implementing fully immutable files

Posted Apr 20, 2019 2:44 UTC (Sat) by epa (subscriber, #39769)
In reply to: Implementing fully immutable files by wahern
Parent article: Implementing fully immutable files

It comes back to the two meanings of ‘read-only’ which are often confused. There is read-only in the negative sense: you are not allowed to write to this file. That is provided by the permission bits. But there is also a positive contract sense of ‘read-only’: the file will not change, now or in the future, because neither you nor anyone else can change it. So while it’s conceptually okay to tighten permissions for new open() calls and yet have existing file handles keep the access that was originally granted, it’s not okay to break a promise that the file would be forever immutable — code relies on that property being honoured.

(You can compare the different meanings of ‘const’ or ‘readonly’ in languages like C++, Java and C# for another example of how an object can be read-only for you, or have a positive guarantee that it won’t be mutated while you hold a reference to it. Locking in database systems is another place where you have to separate the two meanings.)

You may be right that in practice it makes little difference. Immutable files are a specialized feature. But if you’re going to have them at all, surely they should be implemented properly. A guarantee of immutability isn’t worth much unless it holds all of the time.

Implementing fully immutable files

Posted Apr 20, 2019 5:59 UTC (Sat) by lkundrak (subscriber, #43452) [Link] (7 responses)

> But there is also a positive contract sense of ‘read-only’: the file will not change, now or in the future, because neither you nor anyone else can change it.

Unless you, of course, turn off the immutable bit.

I'm quite honestly having trouble finding it hard to understand the use case where the immutable files provide any sort of useful guarantee.

Implementing fully immutable files

Posted Apr 20, 2019 12:21 UTC (Sat) by mikemol (guest, #83507) [Link]

These start to come up when you talk about regulatory compliance, and guarantees like these are just the sort of thing one is occasionally asked to make.

I could easily construct a high-confidence system that relied on the audit framework to tell me when someone is playing with the immutable bit without the overhead of logging on every write attempt to the file in question, for example. Then, I can rely on the immutable bit (with some restrictions) as I make an assertion that a file does not, shall not change.

I can see use cases in antivirus frameworks, configuration management frameworks, logging and auditing frameworks, and so on. Effectively, any system where demonstrable, positive control over a system accessible to untrusted individuals.

It's not a magic bullet, but a useful armor layer.

Implementing fully immutable files

Posted Apr 20, 2019 13:01 UTC (Sat) by epa (subscriber, #39769) [Link] (3 responses)

Good point — I would have expected the immutable bit to be permanent, if it were to be useful in practice. (To turn it off you would have to copy the contents to a new file with a new inode number.) Maybe given that only root can turn it off, it still provides some useful property in a system where normal operation is all non-root?

Implementing fully immutable files

Posted Apr 22, 2019 16:39 UTC (Mon) by wahern (subscriber, #37304) [Link] (2 responses)

It *is* useful, even with the way it's currently implemented. For example, exploding a tarball--normally you *want* it to be able to overwrite files lacking write permission bits. Such cases are rather niche, but the complexity is negligible so worth it.

I'm sure some people would find the proposed behavior of revoking mmap access useful, too. But the additional complexity is *tremendous* and, IMO, not worth the marginal benefit, even if there are a handful of organizations that *must* have the feature. I mean, if they really need such behavior they can always just terminate all processes with open file handles after making a file immutable. Messy, but at least the mess doesn't become a long-term maintenance burden for everybody else. It's a dubious guarantee, anyhow, considering how easy it will be to accidentally break the invariant.

Implementing fully immutable files

Posted Apr 22, 2019 19:44 UTC (Mon) by wahern (subscriber, #37304) [Link]

Correction: I meant, normally when exploding a tarball you want it to overwrite files without write permission bits because you're replacing the whole tree, but sometimes you don't and setting a file immutable makes the untar operation blow up. It's a fail-safe. There's some cleaning up to do but less than if that critical file was removed.

Implementing fully immutable files

Posted Apr 22, 2019 20:15 UTC (Mon) by rweikusat2 (subscriber, #117920) [Link]

This feature has existed in its present form for at least 18 years, probably more. It even used to be documented incorrectly as

"no data can be written to the file"
(Debian 7 man page)

someone apparently noted that this wasn't accurate and corrected to documentation to

"the file can not be opened in write mode."
(http://man7.org/linux/man-pages/man1/chattr.1.html)

I seriously doubt that there's any organisation on this planet which suddenly "must" have this feature. Methinks this is more something like a bored Oracle guy making undirected changes to a codebase (possibly "a sufficiently well-connected, bored Oracle guy that such undirected changes actually get accepted instead of being stonewalled").

Implementing fully immutable files

Posted Apr 21, 2019 0:30 UTC (Sun) by mm7323 (subscriber, #87386) [Link]

Searching lead me to one interesting use case - marking mount point directories immutable to prevent accidental creation of files when the filesystem isn't mounted there. It seems a bit niche though.

As for security guarantees, wouldn't something like SElinux be more appropriate, fine grained and auditable than this mechanism? That said, I have no idea if SElinux or similar behave sanely if policy is changed while files are already opened or memory mapped...

Implementing fully immutable files

Posted Apr 22, 2019 15:15 UTC (Mon) by janfrode (subscriber, #244) [Link]

Spectrum Scale/GPFS has a more useful immutability function, where files are made immutable for a given period, and you can’t reset it without deleting the filesystem/fileset:

https://www.ibm.com/developerworks/community/wikis/home?l...