On Mon, Aug 11, 2003 at 04:47:31PM +0100, Sam Vilain wrote:
> 
>     Opinion Poll!
> 
>     let's assume each file and directory carry a tag which
>     says "this is a file of context N", where N is the context
>     number of a virtual server.

Hi Sam!

maybe you should have a look at the archives ...

> An idea I just had is to treat it like an extension to the user ID -
> eg, if you are using 16 bit user IDs then the context + the uid is the
> `system userid' of 32 bits, but with special behaviour (such as
> setting a default, meaning `any context', etc) when the context part
> is 0 or 1.  That way, files are uniquely identifiable between
> contexts.

wow! great idea, and it actually works, or at least seems
to, as I use it since october 2002 ... 8-)

http://www.13thfloor.at/VServer/Concepts.shtml

> btw, where would you put those extra bits for each inode, is there
> room in the ext2/reiser/etc reserved structures?  Of course you could
> use the top half of the nice shiny 32-bit UIDs in Linux 2.6 :-)

> This would mean adding syntax to `chown' and/or `chgrp' to specify a
> context name as well as a username (eg, chown [EMAIL PROTECTED]:[EMAIL PROTECTED]
> filename).

http://vserver.13thfloor.at/Linux2.6/index.php?page=Per+Context+Quota

there you have the chctx/lsctx tools too ... what a 
surprise *g* ...

> It could also be a different command, chctx, as suggested elsewhere.
> But personally, it looks like ownership to me.
> 
>      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?
> 
>      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?
> 
>      4) consider a program removing a link to a file with
>         more than one links, should the remaining links ...
> 
>         a) be still 'owned' by the removing context?
>         b) be changed to context zero/one?
> 
> The behaviour should be exactly as if it were owned by a different
> user.

objection, the least thing to consider is
root in different contexts, which you do not
want to be handled like 'normal' users ...

best,
Herbert

> -- 
> Sam Vilain, [EMAIL PROTECTED]
> 
> C++, where only your friends can access your private parts.
> 

Reply via email to