From: Alex Lyashkov (shadow_at_itt.net.ru)
Date: Tue 24 Dec 2002 - 20:43:57 GMT
On Tue, Dec 24, 2002 at 09:08:11PM +0100, Herbert Poetzl wrote:
> On Tue, Dec 24, 2002 at 10:51:19PM +0300, Alex Lyashkov wrote:
> > Hello Herbert,
> > > > you have plain for create that ?
> > >
> > > well, I already did, but Jacques had a look on it,
> > > and said "that's not the way I would do it ...", but
> > > as far as I know it's the only way it has been done
> > > till now, and as far as I am concerned, it's the best
> > > way to do it ... anyway your mileage may vary.
> > >
> > i found other way to store context numbering at inodes.
> > I add 2 ioctl`s to inode. itself context number stored in reserved
> > for linux fields at ext2 inode.
>
> hmm, yes I thought about that too, I almost implemented
> this, but I thought the idea to combine 16bit uid/gid
> and 16bit context id to 32bit uids would make life a
> lot simpler because it has several advantages:
>
> * independant from filesystem (if it has 32bit uid/gid)
> * you do not need any modifications (ioctls etc)
not need. only add ioctls for change context.
> * chown, chgrp, ls can be used to change/list context info
system utilites not need modification. context info used only for control permision
> * quota will automagically separate users from different contexts
if vroot's introduce as "mount --bind" (simular nfs via loopback) it`s can separate
by kdev for quote hash. but in other case (read/write) use old mount point for unificate
diskspace.
>
> the real advantage, in my opinion, was to make context
> zero readable/accessible for any context, and do an
> automatic context migration at change/write/etc ...
>
i my opinion context "zero" can do "system" context with real devices/memory/etc..
and not accessable without special permission.
Best regards,
Lyahkov mailto:shadow_at_itt.net.ru