hi folks, Here is the revised interface. I believe it takes into account the issues raised so far - further suggestions are also welcome, of course. Man pages for the system calls are available from
At 03:32 05/12/01, Nathan Scott wrote: Here is the revised interface. I believe it takes into account the issues raised so far - further suggestions are also welcome, of course. Hi, Looks good to me.
Hi Nathan, I still don't like the class parsing inside the kernel, it's hard to see what is good about that. Is there a difference between these two?: long sys_setxattr(char *path, char *name, void *
hey there. I guess it ultimately comes down to simplicity. The IRIX interfaces have this separation of name and namespace - each operation has to indicate which namespace is to be used. That becomes
No compelling reason - I've switched to your version, new patch is here: http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfsmisc/xattr.patch cheers. -- Nathan
Right now we have two namespaces, user and system. That's one bit of information, and the proposal is to represent it with 5-7 bytes, passing it on every call, and decoding it with a memcmp or simila
hi Daniel, Andreas and the security folk have long been investigating "trusted" and "owner" namespaces too. See Andreas' web pages for more discussion on those. I see no reason to impose such arbitra
It may well be, however, the one call that has flags, set, is looking a little irregular sitting there on its own. We're inventing an API here for which we don't have a lot of guidance from existing
hi Daniel, Not sure what to say to that ... the API is practical, flags seem to make sense for that call (the flags give the slightly different "set" semantics, but it is still "set"), IMO they don't
This is looking OK as far as EAs go. However, there is still no mention of ACLs specifically, except an oblique reference to ""system.posix_acl_access". Is there no consensus on this? In previous pr
hi Stephen, Yup - there's little mention of ACLs because they are only an optional, higher-level consumer of the API, & so didn't seem appropriate to document here. We have implemented POSIX ACLs abo
Nathan Scott wrote: In a way there's consensus wrt how to do POSIX ACLs on Linux now, as both the ext2/ext3 and XFS ACL projects will be using the same tools, libraries, etc. In terms of other ACL ty
Unfortunately, if there are many filesystems wanting to use posix ACLs, then standardising the API is still desirable. But the ACL encoding is still hobbled: there's no namespace for credentials oth
Author: "Mr. James W. Laferriere" <babydr@xxxxxxxxxxxxxxxx>
Date: Mon, 10 Dec 2001 11:00:06 -0500 (EST)
Hello Stephen , Is this the only attribution ? Just love those 'we won't share security info with you unless you are member or pay.' . Sorry , JimL +--+ +--+
There are other references in the paper: I've appended them below. One, in particular, seems to talk about quite similar concepts: http://www.usenix.org/publications/library/proceedings/sec2000/acha
Probably. Excuse me? This is a paper presented at a conference, not a security bug report in existing code. I can totally understand having to pay for proceedings from a conference. John
True. [credential examples deleted] So you are particularly interested in more general "qualifiers" (in posix acl entry speak:). Some people are also interested in more general "permissions" for ACEs