From: Herbert Pötzl (herbert_at_13thfloor.at)
Date: Sat 09 Aug 2003 - 13:45:24 BST
On Sat, Aug 09, 2003 at 01:43:22PM +0200, Mark Lawrence wrote:
> On Sat, 9 Aug 2003, Herbert Pötzl wrote:
>
> > Opinion Poll!
> You're on!
thanks for taking the time ...
> > 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
I agree, the only reason for a change would be the use
of some unification tools, but maybe this should be solved
differently, or ignored at all ...
> 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.
forgot to mention,
consider a set of utilities lsctx, chctx, ... able to
read/modify those tags if you have the required priviledges ...
>
> > 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.
okay, so basically except from unification, which would/should
change the files back to context zero/one links to/from
another context should be considered not doable/accessible at
all. correct me if that's not what you meant.
best,
Herbert
> Regards, Mark.
> --
> Mark Lawrence
> mark_at_holderbank.com