From: GuruJ (GuruJ_at_mbox.com.au)
Date: Sun 10 Aug 2003 - 09:00:55 BST
Mark's responses are pretty much what I would have said as well.
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.