SFTP: semantics of writing an entry to an immutable file in a writeable directory

[davidsarah]

If we have a write cap to a Tahoe directory, or write permission to a Unix directory, we can always replace entries in that directory.

In Unix filesystems, there are also write permission bits on individual files. If the applicable write permission bit is not set on a file, then attempts to open the file for writing will fail with an EPERM error, even though the directory entry could be changed to refer to a different file.

(Note that, non-standard extensions aside, files/inodes in a Unix filesystem are mutable. If a file is hardlinked from two directory entries, the hardlinks are aliases to the same mutable file/inode object.)

The previous SFTP code did not support the case of a non-writeable file in a writeable directory. I.e. if the path passed to an open request with FXF_WRITE or FXF_CREAT flags refers to an immutable file at the time of the open, then the request will succeed, and the directory entry will be changed to refer to a new immutable file when the handle is closed.

This is also true for the new implementation as of ​ticket1037 r4377, but in addition we support opening mutable files. A read-only mutable file (that is, one whose entry in the parent directory is a read cap) cannot be opened for writing, even when the parent directory is writeable.

Zooko expressed concern on IRC that the ability to express non-writeable directory entries referring to mutable files, but not to immutable files, was inconsistent and might cause compatibility problems. (I hope I've expressed his concern correctly.)

I propose to address that by adding an optional "no-write" field in the metadata of directory entries. The default would be False. When this field is set to a non-empty string in an entry pointing to an immutable file, the write permission bits reflected to SFTP clients would have the 'write' bits cleared, and attempts to open the entry for writing would fail. (The field would have no effect on entries pointing to directories, unknowns, or mutable files.)

Note that the permissions reflected to SFTP clients always have 'owner', 'group' and 'world' bitfields the same. When the permissions are set by a client, the value of 'no-write' would be taken from the owner write bit.

Pros:

• applications that rely on getting an EPERM error when opening a file for writing when the file 'write' permission is not set, will work correctly.
• since files not created via SFTP, or files created via SFTP with 'owner' write permission, will be automatically replaced on write as they are now, there is little usability cost in the common case.
• clearing the write bit might be useful to prevent accidental overwriting of a directory entry.

Cons:

• the model is slightly more complicated (but no more so than POSIX/Unix).
• the cleared write bit may appear to be a security restriction, but isn't.
• the semantics are still not quite the same as POSIX/Unix. Unix file permissions are on inodes; Tahoe metadata is on directory entries. So for example, if a file is linked from two directory entries, in Unix a 'chmod' on that file via either path will affect attempts to open the file via the other path, whereas in Tahoe (via sshfs, say), only the specified directory entry would be changed. This is unlikely to make much difference in practice.

[davidsarah]

A closely related issue is what should happen when you clear the owner write bit on an entry pointing to a mutable file or mutable directory. This could diminish the write cap to a read cap. However, unlike the corresponding operation on Unix permissions (for the file owner), that would not be reversible -- it would not be possible to restore the write cap by changing the permissions back.

The advantage of this is that you would be able to use chmod to create read-only structures in the Tahoe filesystem. Without it, there is no way to create a read-only link to a mutable directory (or file) just using SFTP.

[zooko]

fixed by de95140b7b58b4b0, 29a06457d25bcea8, 2a791b0d05b8bab4.

Hm, note that the part about diminishing a read-write cap to a read-only cap when the no-write flag is set is an actual security restriction.