[LU-17957] set immutable with "future atime + chmod a-w"

• Type: Improvement
• Resolution: Unresolved
• Priority: Major
• Labels: medium
• Assignee: WC Triage
• Reporter: Andreas Dilger

Description

Implement a POSIX interface to allow non-root users to set a file immutable, in a similar manner to GPFS:

• set the file access time into the future: "touch -ac --date='1 hour' <file>"
• remove all write permission to the file: "chmod a-w <file>"
• internally this will result in the "FS_IMMUTABLE_FL" to be set on the file if the user is the file owner or has the CAP_SYS_IMMUTABLE capability

Implement a POSIX interface to allow non-root users to set a file append-only, in a similar manner to GPFS:

• set the file access time into the future: "touch -ac --date='1 hour' <file>"
• remove all write permission to the file then add them back on a file with size = 0: "chmod a-w <file>; chmod u+w <file>"
• internally this will result in the "FS_APPEND_FL" to be set on the file if the user is the file owner or has the CAP_SYS_IMMUTABLE capability

The immutable/append-only flag itself should prevent any modification of the existing file contents, regardless of how the flag was set.

For files with a project ID that has the "PROJECT_FLAG_COMPLIANCE" attribute set (LU-14915), files with atime in the future should prevent the FS_IMMUTABLE_FL and FS_APPEND_FL attribute from being removed from the file, even by the root user or process with CAP_SYS_IMMUTABLE. The atime of such files can be increased but never decreased. Once the atime has passed, files with project ID with PROJECT_FLAG_COMPLIANCE can be removed, but not modified or have the FS_IMMUTABLE_FL or FS_APPEND_FL removed.

Tests for this feature should not set the atime too far into the future (e.g. not more than a minute or two), so that the test does not need to wait very long until the atime is in the past. However, in production we may want a minimum threshold for "the future" to avoid issues with clock skew accidentally triggering this functionality.

Issue Links

• is related to: LU-18679 Allow setting an "immutable inherit" flag on a directory

Comments

[Andreas Dilger]

There are a number of places where this functionality could be implemented:

• client - has the drawback that the client is the most easily modified.
• MDS - needs to also set the FS_IMMUTABLE_FL flag on the OST objects. We would need to trust the MDS clock in this case (e.g. NTP).
• ldiskfs - needs a patch to ldiskfs, but has the benefit (drawback?) that it would also prevent direct removal of the FS_IMMUTABLE_FL from the underlying inode.

None of these approaches can entirely prevent the removal/modification of an immutable file by themselves, because a sophisticated attacker can still patch the kernel to bypass these added checks. However, if the functionality is implemented on the MDS and/or ldiskfs, this would at least require a sophisticated attack with a root compromise of the server, which is considerably more difficult than mounting the filesystem with a modified client.

It would be nice if it were possible for regular users to use "touch -ac --date=FUTURE_DATE FILE; chattr +i FILE" (and ideally also "chattr +i FILE; touch -ac --date=FUTURE_DATE FILE") for files (i.e. it shouldn't matter how the FS_IMMUTABLE_FL is set initially, and it should be possible to advance the "keep until" date for an existing file).