Modules in C/C++?

It looks like there is again a proposal to standardize modules in C++. This would be very nice if successful. While I don't care that much about C++, it has been the trend lately that ISO C picks up useful C++ features (e.g. threads). So who knows, maybe, maybe we could finally get modules in C, after 40 years? Pretty please?

On Limits

Past experience has shown that for any number N, and for almost any object O, the statement "we'll never need more than N of O" is invariably untrue.

Casper Dik

Assessment of Stepan Henek's thesis Security containers and access rights in HelenOS

• no justification why kernel must be modified to cache the tickets being used by a task
• does not properly analyse UNIX file permission model and how it allows delegation of administration - no discussion of who and when can change owner and mode, s{u|g}id, sticky bit
• interestingly there is actually no proposal for security containers in HelenOS
• many types of tickets - it's not clear whether they are useful for anything and how one would choose among them
• no real analysis/discussion of how the file permissions should be implemented and how it would (dis)allow common tasks such as sharing files, giving away files, (not) enforce users to follow some administrator-given rules for setting file permissions, etc.
• it claims administration can be delegated thanks to the permissions on the individual RBAC virtual folders, but that's not true, these are too low-level and any useful permission given away will necessarily lead to privilege escalation (or at least no (counter)example is presented)
• in the implementation, environment variables are introduced and used (without thought) for the sake of determining the default OGID for newly created files

some more thoughts/ideas:

• not only that the almighty administrator cannot delegate his privileges, an ordinary user cannot delegate his privileges either (just like in UNIX) - no hierarchical principals
• no way to enforce or even suggest permissions for files/directories under a subtree (cf. default ACLs)
• single OGID for a file might be inflexible, especially if object groups can only be created/permissions set by the almighty administrator

In summary, the proposal:

• might make it slishtly easier for an admin to assign permissions to a user
• does not seem to allow any better delegation than the standard UNIX model
• does not make proper analysis of what the model actually allows/ensures w.r.t operations on files and directories
• introduces a new type of kernel resource with no obvious return value
• makes it necessary to make a system call which queries the tickets (i.e. communicates with) a foreign task for any authorization operation, making it a communication-intesive operation (despite that IPC as such is not used)

Back to the drawing board, I say!

I'm going to FOSDEM

You can find me in the Microkernel OS Devroom.