Chris Mason wrote:
>
> --On 10/27/00 14:33:33 -0700 Hans Reiser <[EMAIL PROTECTED]> wrote:
>
> > The atomic restriction can be enforced in a component separate. I mean,
> > ACLs have all sorts of restrictions on them, and atomicity is one of a
> > great many of them, so you have to have a separate component restricting
> > things anyway. All we are doing is making it possible for that ACL
> > implementation to use a nice toolkit that will also be used by things
> > other than ACLs.
> >
> > You could do the following syntax:
> >
> > /process/range/(X,Y)=>/filename/atomic/ACL/1;/process/buffer/(A,B,C)=>/fi
> > lename/some_non_ACL_attribute;/process/range/(U,V)=>/filename/atomic/ACL/2
> >
>
> This really confuses me ;-) The process is writing from some range of its
> memory directly into a filesystem ACL stream? Where are the
> restrictions/description of what an ACL looks like, or how it behaves, or
> how this process interacts with another process working on the same ACL?
> How about type checking of the ACL entry being copied in?
Specifying ACL invokes the ACL method on all I/O to that non-stream attribute.
>
> Security related APIs need to be very specific. They define an object,
> enforce how/when to use it, and leave no doubt at all about what will
> happen when each operation is done. Sorry, but I just don't see that in
> your syntax descriptions.
The specified ACL method does it, however you want it.
>
> > where range is a non-stream range of bytes in the process address space,
> > and ACL 1 and 2 are updated atomically, and some_non_ACL_attribute is
> > some irrelevant thing thrown in to make the example which is not updated
> > atomically and is a stream. I am not sure of the syntax here, you could
> > perhaps do better with the following (I have to think about it):
> >
> > /atomic/(/process/range/(X,Y)=>/filename/ACL/1;/process/range/(U,V)=>/fil
> > ename/ACL/2);/process/buffer/(A,B,C)=>/filename/some_non_ACL_attribute
> >
> > or maybe
> >
> > [atomic,(/process/range/(X,Y)=>/filename/ACL/1;/process/range/(U,V)=>/fil
> > ename/ACL/2)];/process/buffer/(A,B,C)=>/filename/some_non_ACL_attribute
> >
> > but in any event I hope you can see that some syntax is possible to
> > design for it that will work well. The atomic restriction is not enough
> > of course, you really need an ACL_write_constraint substituted for atomic
> > in the examples above where ACL_write_constraint imposes all sorts of
> > restrictions relating to ACLs.
> >
> > I mean guys, you may be able to shoot holes in my syntax, and I hope you
> > will so I can improve it, but the fundamental idea I am pushing is that
> > the following qualities should be kept orthogonal:
> >
> > * effective interaction with small things (I say they should all be files)
> >
> > * whether the things stream (whether or not they do, they can still be
> > files)
> >
> > * whether updating a set of them is atomic (they can still be files)
> >
> > * whether there are contraints on the allowed values (they can still be
> > files, it would be nice if the msu T-system guys implemented those
> > constraints for us so that we can get a decent implementation of recalc)
> >
>
> The FS might keep them orthogonal inside, but for an ACL api, they all need
> to be combined together into a set of known and reliable features. The FS
> can implement things any way it wants to, but the interface needs to be
> very precise.
Yes, it needs an ACL method.
>
> -chris
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
