On Tue, Oct 24, 2000 at 01:46:49PM +0100, Stephen C. Tweedie wrote:
> > Shure there should be lowlevel access to the eas for user-EAs or some
> > special cases, but for the main usages (ACLs, Filesystem Capabilities,
> > MACs) there should be a special high-level API instead.
> > So instead of using the EA-API for your ACL lib und progs, you use ACL
> > syscalls instead. Theses map to EAs as specified in the ACL kernel module.
>
> I don't understand. This is exactly why I specified that there be an
> ATR_POSIXACL attribute family. That family *is* a high level
> interface to ACLs. The whole point of the API was to avoid having to
> use the low-level attribute functions when dealing with complex
> objects like ACLs!
Yeah. But I think it is not clearly enuogh separated.
I think we should have one set of plain name/value syscalls and one
set of acl syscalls, because ACLs have nothing in common with EAs
besides that ACLs can be implemented using EAs as backing store.
> The whole point of the proposal was to allow us to have the extended
> attribute and the ACL functionality clearly separated, but still
> presented in a uniform API.
And I think that ACL and EA should be separated because they are
completly different things.
> The ACL API *has* to be done in some form
> of extensible way anyway, because different existing filesystems have
> different semantics and different sets of ACL entry types. The
> attribute family ATR_POSIXACL is a generic ACL API for any filesystem
> that enforces POSIX ACLs, but other filesystems may want a different
> attribute family: ATR_AFSACL, for example, would work in terms of
> Kerberos tokens instead of Unix IDs, and would offer a different set
> of permissions bits.
Yeah. I think your family-like API doesn't belong in the EA layer but in
the high-level ACL layer. This ACL layer would have it's own syscalls,
e.g. (very similar to you EA API):
sys_acl (char * filename, int op, int acl_type,
struct fs_acl * old, size_t * old_len,
struct fs_acl * new, size_t new_len);
(same with sys_facl)
and struct fs_acl_t defined as (also very similar to you struct attrib):
struct fs_acl {
char * name;
size_t * name_en;
char * val;
size_t val_len;
}
The EA API would be the one proposed by Andreas:
sys_eattr (char * filename, int cmd,
const char * name, char * value,
size_t size);
(same with sys_feattr)
If you say "this looks very similar to my proposal", yes, it does.
The major difference is that it reduces complexity by not putting
together two different things.
> Or am I missing something? I don't see why the proposed API doesn't
> provide exactly the sort of high-level ACL API you want.
Yes it does. But I don't like mixin the low-level and high-level API
in the same syscall.
Christoph
--
Always remember that you are unique. Just like everyone else.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
