OSDev.org

I think it really depends on the design of the OS, but it might be good.

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. So I thought that a sticky bit should:

- 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.
__________________________________
..................................................
__________________________________

Another idea is:

- 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?

We would need to tell the function what to write, it could be snapshots, changed CPU registers, changed variables, steps given and described to see how the code lines actually do things as the program executes.

For example, if we use a menu, take a snapshot and then write text, HTML, image and maybe video files of the process.

It would be like a book full of good information, but it would actually be derived from writing from the program using programmatic automation, which writing we could improve over time to make it more human readable and easy to understand, but actually showing how the program actually does things, in a way that promotes reimplementations with new code from scratch, now more easily, with a full example.

Although it would require modifying existing programs with sources so that they show something more like a high quality book than a log.


__________________________________
..................................................
__________________________________
It also looks like the names we all or most of us choose here are more emotive than those from bigger projects like GNU. It probably clearly shows how our projects are more personal, while projects like GNU ones are much more collective and targeted to tasks that existed previously.

Hi,

~ wrote:I think it really depends on the design of the OS, but it might be good.

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. So I thought that a sticky bit should:

- 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.

There are multiple operations that can be done on a file (e.g. create, read, write, change name, change attributes/permissions, copy, move, delete). With multiple users this forms a permission grid (e.g. 8 operations * 10 users = an 8*10 grid of flags saying who can do what). A security model is something that is able to generate this permission grid (and then use the result to allow/disallow operations) from whatever information is available (kept as part of the file's metadata) even when new users are added afterwards. Maximum possible coverage is where the information kept as part of the file's metadata is able to represent every possible permutation of the permission grid (e.g. 2 states ** (8 operations * 10 users) = 2**80 = 1208925819614629174706176 permutations). Of course maximum possible coverage is too expensive in practice; however it is a useful concept to measure/rate how good a permission system is. For example, a single flag provides 2 permutations of the permission grid, which (for 8 operations and 10 users) means 2 supported permutations out of the 1208925819614629174706176 maximum.

This rating system can be extended with weights. For example, you can say that confidentiality (preventing unauthorised people from being able to see sensitive information) and integrity (preventing unauthorised people from being able to create/modify sensitive information) are more important than other concerns, and design a system of weights to reflect the importance. In this way you can design a robust method of accurately rating and comparing security systems.

With a rating system like this (without actually determining weights or doing any of the calculations), it's obvious that "one flag" isn't even slightly good - the old *nix permission system ("RWX, user/group/anon") would get a significantly better rating, and modern permission systems (e.g. ACLs, capabilities, etc) get significantly better ratings than the old *nix system.

~ wrote:Another idea is:

- 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?

Lots of software already supports logging (and often provides ways to enable/disable categories of things logged). One example (that a lot of people here are likely to be familiar with) is Bochs, which has very configurable logging (allowing the end user to set a different "log level" for each category of thing).


Cheers,

Brendan

~ 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.