~ wrote:
- Grant read access. As soon as any modification is attempted, the system must create a copy of the file, then apply the modifications to it and redirect all accesses to it. The copied file should internally have the name of the user as a prefix and then the file name. It could be created in a mirror directory with full access for the given user and could optionally be directly accessed. It would simply be a redirect if a sticky file was ever tried to be modified by another user.
I see the merit, but probably as separate feature, rather than as extension to the sticky function. One danger I see is that a file change can create viral effects. The original information will be saved, but the system may still be compromised. There are certainly scenarios where it will be useful however. Also, it needs to interact with the storage quotas, depending on if the ownership changes. If you are interested, you can look up reflinks (see cp --reflink) and check how they compare.
Edit: I should note that reflinks work only on certain filesystems, like btrfs.
~ wrote:
I was thinking that a sticky bit is meant to avoid deleting a file. But a file can be effectively deleted without removing its entry from the file system, for example destroying part of its contents and headers or just truncating it.
For the sticky bit, I believe the idea is to refine the permissions model for directories. The Unix permissions are designed for opaque objects. This is ok for files, but shoehorned for directories, because they operate at the record level from the OS's point of view. The result is that simultaneous modification in the same directory from multiple users opens up many exploits. With the sticky bit, assuming that the creator is the owner of the file and has himself added the path to the directory, like the /tmp directory, the path record becomes essentially owned by him, so to speak. Generally, this is not about file nodes and file contents, but path management. The file's existence is affected as a byproduct.
Note that the path components, the metadata, and the contents can create different security concerns. If you give someone write permissions to the file, you are exposing the data. Similarly, write permissions to a directory, exposes the directory structure. My point is, those different aspects affect the system operation in different ways. Since the file's existence is byproduct from reachability, if some file gets added in a privately owned directory, it will not be removed from the system. As long as that directory is not deleted, it will guarantee that at least one path to the file remains. No sticky bit required.
~ wrote:
- Why not create a special version of a program, our own fork, and add a function named WriteBookFromProgram(...), which we would simply call repeatedly across the whole program whenever we do something interesting, so that the function writes the sequence of things that are happening?
I cannot infer from the description weather this is targetted at administrators or developers. There is a preconception in the Unix world that all homosapiens are destined to be someday hackers.
In any case, I would be happy to see OS infrastructure for traces of my functions, their parameters and local variables, similar to ltrace and strace. There are many technical problems with that, particularly relating to vast information volume in the trace stream, so it must be one intelligent system. In fact, being able to provide additional metadata hints (say, as pragma) to pre-filter the output wouldn't be unwelcome.