From: Sam Stickland (sam_ml_at_spacething.org)
Date: Mon 11 Aug 2003 - 14:48:10 BST
Likewise.
----- Original Message -----
From: "GuruJ" <GuruJ_at_mbox.com.au>
To: <vserver_at_solucorp.qc.ca>
Sent: Sunday, August 10, 2003 9:00 AM
Subject: Re: [vserver] Context Tags Opinion Poll ...
> 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.
>