--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?
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.
> 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.
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
