Intuitively, this method fits in with what I see vserver as trying to accomplish.
-- GuruJ.
Mark Lawrence wrote:
On Sat, 9 Aug 2003, Herbert P�tzl wrote:
Opinion Poll!
You're on!
1) if the almighty context zero/one modifies files of another context ...
a) the files/dirs to keep their context? b) the files/dirs change to context zero?
I think a) is a better option. Consider what currently happens with file ownership, or file permissions. It would make sense to have the same style of behaviour. I suggest the use of a 'chctx' command (like chmod, chown etc) to change the context of a file from the zero/one contexts.
2) if a program of context N encounters a file of context M, where N != M ...
a) on modify change the file to the new context? b) do not allow access to files from other contexts except context zero/one? c) allow modification while keeping the file in its 'original' context?
Is not the whole point of a security context to keep the contexts' separate? Go for b). Treat N!=M as a read permission attribute.
3) consider a program creating a (hard)link to a file in another context (including zero/one), should ... a) the file change to the 'new' context? b) the file keep the old context? c) this operation be disallowed?
I would suggest disallow this, with one exception.
My philosophy is that contexts are always separate. As far as I know, the only reason to have any relationship between contexts is to save memory and buffers (are there other reasons?)
For this case, it might be useful that linking from any context to a file in a special context (say context 1) _is_ allowed, but invokes a copy-on-write function when the context attempts to write to the file.
Regards, Mark.
