From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Tue 24 Dec 2002 - 22:21:01 GMT
On Tue, Dec 24, 2002 at 11:43:57PM +0300, Alex Lyashkov wrote:
> 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.
hmm, I guess you have to explain this, because I
seem unable to follow your thoughts (e.g. add some code)
> > * chown, chgrp, ls can be used to change/list context info
> system utilites not need modification. context info used only for
> control permision
so you check for context on access/change?
but how will you move some files from context A to
context B within the physical server?
> > * 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.
mount --bind is a virtual filesystem feature, not a
filesystem itself, I doubt that you can discriminate
on such a mount information, but I'm looking forward
to test some code ...
> but in other case (read/write) use old mount point for unificate
> diskspace.
??? please explain
> > 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..
thats true, but what is the relation to my writing?
> and not accessable without special permission.
???
please clarify,
best,
Herbert
> Best regards,
> Lyahkov mailto:shadow_at_itt.net.ru
>