"Stephen C. Tweedie" wrote:
>
> Hi,
>
> On Thu, Oct 26, 2000 at 09:26:22PM -0700, Hans Reiser wrote:
> > You are making extended attributes different from files in more than name. This
>is deeply and
> > fundamentally wrong.
>
> ACLs, MACs etc _are_ fundamentally different. They don't have a byte
> stream structure. They are more like datagrams than tcp streams, to
> take a networking analogy. There are plenty of file attributes which
> are not streamlike: mode, owner etc. This is nothing new.
>
> The API here is designed *exclusively* for non-streamlike attributes.
> If your filesystem can actually implement stream-like attributes, then
> you can also use the filesystem namespace to access those attributes
> --- that's great.
Then design a non-streamlike file api, and make being non-streamlike a feature
orthogonal to
everything else. I don't see why being non-streamlike requires that an extra copy be
added to
assemble the data into your struct.
>
> > > I am *not* going to implement database-style transactions just for
> > > something which is basically an extended chmod()! It is also quite
> >
> > then don't misfeature atomicity in! If you can't do it right, don't code it into
>VFS so that we all
> > get stuck with it!
>
> Huh? ACLs *must* be updated atomically. You have no choice.
> Anything else is a security hole. It's not optional.
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)=>/filename/some_non_ACL_attribute;/process/range/(U,V)=>/filename/atomic/ACL/2
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)=>/filename/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)=>/filename/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)
probably other things were also mentioned
> > > impossible to implement arbitrary transactions over filesystems such
> > > as NFS, but we still need ACL APIs for that.
> >
> > So don't make atomic a filesystem that doesn't support atomicity. Why do you want
>to do that? What
> > is even crazier is that you blame me for this requirement of yours which is
>supposedly a requirement
> > of mine. If it doesn't support atomicity it ignores the atomicity specification
>by the user, if it
> > requires atomicity it imposes it on the user, if it is well designed it does as
>asked, what is the
> > problem?
>
> Calm down --- who said anything about blame???!!!
>
> I already said that "transactional" != "atomic". "transactional"
> means updated atomically on disk. "atomic" in memory is a separate
> issue, and ACLs only need that. Atomic in memory is much easier ---
> we only need a lock around the update, we don't need any fancy on-disk
> write ordering tricks.
>
> If you mean transactional on disk, then we agree --- if the filesystem
> can support it, that's great; if not, no big loss, we weren't
> promising anything anyway.
Do databases make things transactional on disk only? I suspect not.... it wouldn't
make much
sense.... though to do otherwise is probably much harder to code.....
>
> > You have some misdesigned filesystems you want to support by forcing all the rest
>of the filesystems
> > to be misdesigned. Make misdesign optional not mandatory. That means don't give
>us a single way of
> > doing things that combines several different features in a non-orthogonalized way
>that forces us to
> > take all features when we only want one of them.
>
> I agree --- that's why we need an ACL API which doesn't require the
> use of a named-file byte-stream. The two pieces of functionality are
> orthogonal. I don't want to get in the way of anybody who wants to
> implement named streams, but there are a ton of existing ACL
> implementations which don't work that way and we need to support them.
>
> Hans, I am *NOT* suggesting that reiserfs must implement all its
> attributes in any specific way. However, there is most definitely a
> need for some form of fairly standard way to access specific
> attributes such as ACLs and DMAPI attributes.
>
> Cheers,
> Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
