|To:||"Stephen C. Tweedie" <sct@xxxxxxxxxx>|
|Subject:||Re: Implementing POSIX ACLs - was: Re: [PATCH] Revised extended attributes interface|
|From:||Anton Altaparmakov <aia21@xxxxxxxxx>|
|Date:||Tue, 11 Dec 2001 15:15:50 +0000|
|Cc:||"Stephen C. Tweedie" <sct@xxxxxxxxxx>, Timothy Shimmin <tes@xxxxxxxxxxxxxxxxxxxxxxx>, Nathan Scott <nathans@xxxxxxx>, Andreas Gruenbacher <ag@xxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, linux-xfs@xxxxxxxxxxx|
|References:||<firstname.lastname@example.org> <20011211122258.V61575@boing.melbourne.sgi.com> <20011205143209.C44610@wobbly.melbourne.sgi.com> <20011207202036.J2274@redhat.com> <20011208155841.A56289@wobbly.melbourne.sgi.com> <20011210115209.C1919@redhat.com> <20011211122258.V61575@boing.melbourne.sgi.com> <20011211113306.E2268@redhat.com> <email@example.com>|
At 14:34 11/12/01, Stephen C. Tweedie wrote:
On Tue, Dec 11, 2001 at 01:30:16PM +0000, Anton Altaparmakov wrote:
You are certainly right here. However, I thought the existing ACL implementation was going to provide the detailed EA specs on top of the generic EA spec. I can see why you would want to reserve certain EAs for ACL use in the EA spec though. It would be just like reserving syscall numbers and that makes a lot of sense...
> It is up to a different API to implement ACLs. In the case of xfs, ext3, > etc, it can have EAs as a backend to the API but in the case of NTFS ACLs > would not be anything to do with EAs.
The existing EA code implements magic "handlers" for system EAs. Undefined magic gets called when you set such an EA. There's no mention about this in the spec.
That is a short coming of the EA spec. Agreed. Or rather it is a flaw in the EA design as there shouldn't be any magic handlers. I have always seen EAs as a means to store things in files that isn't the file data but other random pieces of information. The fs shouldn't care what those are.
So right now the EA code opens up what is basically a named-ioctl back door into the filesystems, and ACLs work on top of that. The existing ACL and EA code is already enormously intertwined.
The ACL API should only use EAs as backing store, no magic handlers attached to the EAs. Then the system would not be open to abuse. The ACL part of the fs can of course make use of the EA backing store if it wants to.
> IMHO a generic POSIX ACL API would never even know that ACLs are stored as > EAs, this should be up to the individual fs and if several fs use EAs it > would make sense to have vfs helpers which all fs can use (a-la generic_* > helpers).
So how are we going to do ACLs on top of EAs? Even if we forget about the ACL API for now, the API between the ACL layer and the EA layer *does* matter.
Indeed. I would favour an abstraction at vfs level and fs specific methods as I described in previous post because this really divorses the two layers.
I know code speaks but I am more interested in making NTFS work properly read-write and only then implement ACLs in it at the moment...
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||RE: using dmapi to sync filesystems (was using xfsdump...), Matthijs van der Klip|
|Next by Date:||Re: kernel updates for 2.4.x kernels?, Eric Sandeen|
|Previous by Thread:||Re: Implementing POSIX ACLs - was: Re: [PATCH] Revised extended attributes interface, Stephen C. Tweedie|
|Next by Thread:||Re: [PATCH] Revised extended attributes interface, Nathan Scott|
|Indexes:||[Date] [Thread] [Top] [All Lists]|