Re: [PROPOSAL] Extended attributes for Posix security extensions
On Tue, 31 Oct 2000, Stephen C. Tweedie wrote: Hi, NFSv4 indeed specifies yet another variant of ACLs. Yep. In fact, it defines a richer environment than POSIX. However, I _think_ that for any POSIX ACL, you can define an NFSv4 list which is equivalent in all details (although the reverse is definitely not true). NFSv4 defines additional permissions. Unless I've missed something again, there's no mapping for Posix ACL_MASK entries, though. Hmm --- given any POSIX ACL you can define an NFSv4 ACL which gives the same permissions, even including ACL_MASK, but you probably can't make one which has the same semantics on subsequent chmod() modifications of the group permissions bits. It would indeed be possible to present the permissions defined in a POSIX ACL as an NTFSv4 ACL by applying the ACL_MASK entry before constructing the NFSv4 ACL. Subsequent chmod's would cause havoc, though. The whole point in having the ACL_MASK entry is to ensure this sort of interaction works "as expected". I think constructing an NFSv4 ACL that cannot be translated back into an identical POSIX ACL is pretty worthless. Maybe another special ACL entry (like "MASK@") can be introduced. That would be a proprietary extension, and the ACL semantics would derive from the semantics specified for NFSv4. I feel pretty uncomfortable with NFSv4 ACLs. I really had extected NFSv4 to specify a standard format for manipulating various sorts of ACLs, but not a new variant of them. I don't see this as an advantage. Most systems will implement NFSv4 on top of other file systems, so NFS should allow to manipulate the native ACLs. But that's just whining about the past; it already has happened. Andreas. Andreas Gruenbacher, [EMAIL PROTECTED] Contact information: http://www.bestbits.at/~ag/ - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [PROPOSAL] Extended attributes for Posix security extensions
"Stephen C. Tweedie" wrote: On Sun, Oct 29, 2000 at 02:45:32PM +0100, Andreas Gruenbacher wrote: If so, then the client's kernel could map these id's to the proper names when needed, right? Yes. Exactly. You're getting the point --- it is possible for a client to manage the mapping for local uids in a sane manner, because the protocol doesn't impose any semantics on the utf/8 name other than the "id@domain" format. The local client can, if it chooses, use the numeric local uid/gid for the "id" part in all of its mappings, or it can use the username if there is a mechanism for obtaining that. The same lack of semantics on the "id" part which allows local clients to map their own local uid space any way they want, also prevents local clients from doing any useful parsing of remote ids. For remote ids, utf/8 is the only token available. Though this is not my field at all, I've been following this discussion with interest and there's something I'm still missing. Why is it wrong to have a privileged user space program take care of mapping utf/8 to temporary uid? I'm sure there's a reason, I just can't see it. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [PROPOSAL] Extended attributes for Posix security extensions
"Stephen C. Tweedie" wrote:
I have to admit that when I first looked at your proposal I thought it
was overkill, but having followed the thread all the way through I now
have some appreciation of the weird wacky world out there that you are
dealing with. I think your approach is correct. Here are some nits re
your attrib structure.
Nit 1: Do you really need a per-attribute name family? Nit 2:
int-aligned should be good enough for this - I doubt you'll get any
measureable improvement in cache performance with long alignment; int
alignment takes care of alignment-challenged archs and gets 90% of the
cache efficiency. Nit 3: If you make it a *rule* that the record has to
be aligned you don't need the rec_len and it's probably microscopically
faster to traverse anyway because you load one less variable and do the
computation entirely in registers instead (p+=-p3). Nit4: Do you want
the ints to be native-word-sized or fixed-word-size? Since it's a
filesystem interface I'd think fixed. The result is:
struct attrib {
u32 name_len;
u32 val_len;
charname[variable];
charval[variable];
};
This is considerably easier on my eyes, YMMV. Since you've allowed for
names to be up to 4 gig long I'd think there's room in there for a
per-attribute namespace in the unlikely event the attribute familly
needs it.
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
RE: [PROPOSAL] Extended attributes for Posix security extensions
On Tue, 31 Oct 2000, Peter J. Braam wrote:
Good discussion! A few pieces of information from AFS/Coda land below:
Hey there Peter -- hope life is going well for you.
The same lack of semantics on the "id" part which allows local clients
to map their own local uid space any way they want, also prevents
local clients from doing any useful parsing of remote ids. For remote
ids, utf/8 is the only token available.
In fact the world local takes on two meanings. In a large local realm
it is not feasible for a client to cache the entire local realm's user
database and perform mappings. It also becomes highly impractical to
give users the same uid across systems. Interestingly, I think that
neither Coda nor AFS at present support uid mapping.
This was the conclusion I reached also -- right now, my POSIX.1e ACL
implementation has ACL_TYPE_CODA and ACL_TYPE_AFS which mean that the ID
namespace for each entry in the ACL is the "local" AFS/Coda realm, similar
to handling of chown (and that the AFS/Coda ACL semantics hold). This was
also the rationale for introducing acl_check_{fp,file} in addition to the
POSIX.1e acl_check(), as it allows the caller to check the validity of an
ACL and ACL type on a particular target, rather than globally. That said,
I've not attempted to modify Coda or Arla to use the POSIX.1e ACL
interfaces as yet. Assar seemed to have signed off on these ACL interface
changes as being feasible for Arla, but I don't believe they've actually
tried it either.
The interface has proven sufficient to support my "Coda ACLs on UFS"
implementation, given my personal preference for Coda/AFS ACLs, which
binds a complete ACL only to directories, and supports a more
comprehensive ACL rights set (arwid, etc). Not that I expect to force
this on anyone, of course -- it's POSIX.1e semantics or nothing for most
people.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
Re: [PROPOSAL] Extended attributes for Posix security extensions
Hi, On Thu, Oct 26, 2000 at 07:58:57PM +0200, Daniel Phillips wrote: Curtis Anderson wrote: So, I can implement stream-style "extended attributes" using code in libc and a few conventions. I could even simply document the technique and leave it up to the application developers who want EA's to put the required code directly into their application. Wow, I've just implemented stream-style extended attributes without actually writing any code at all! This is where your lucid exposition gets murky. It's not enough to simply document it, you actually have to make the changes in libc, or wherever you plan to make them. That's not the point --- the point is that you are going to have to make these user space changes in any case, whether you have kernel support or not, so there's no need to implement in the kernel functionality which can be obtained in user space for free while you are making those necessary changes. Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [PROPOSAL] Extended attributes for Posix security extensions
Hi, On Sun, Oct 29, 2000 at 03:58:28PM +0100, Andreas Gruenbacher wrote: On Sun, 29 Oct 2000, Stephen C. Tweedie wrote: NFSv4 indeed specifies yet another variant of ACLs. Yep. In fact, it defines a richer environment than POSIX. However, I _think_ that for any POSIX ACL, you can define an NFSv4 list which is equivalent in all details (although the reverse is definitely not true). NFSv4 defines additional permissions. Unless I've missed something again, there's no mapping for Posix ACL_MASK entries, though. Hmm --- given any POSIX ACL you can define an NFSv4 ACL which gives the same permissions, even including ACL_MASK, but you probably can't make one which has the same semantics on subsequent chmod() modifications of the group permissions bits. --Stephen - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [PROPOSAL] Extended attributes for Posix security extensions
Hi, On Sun, Oct 29, 2000 at 02:45:32PM +0100, Andreas Gruenbacher wrote: Except for the "[EMAIL PROTECTED]" issue, which I believe is better dealt with in userspace whenever possible It can't be dealt with in user space when you are setting ACLs on a remote filesystem to grant or deny access to a third party in a different realm. What happens with users the client machine doesn't know about for things like the file owner? What should system calls like stat(2) return? How about chown(2)? ACL's aren't the only problem here. Of course. There are several different possible implementations. You could restrict local processes to have the rights of a limited subset of the possible utf/8 user strings, and map any other remote user strings to the nobody id. chown is much easier --- the local machine can easily decide on what mapping it uses from local uids to remote utf/8 identifiers. ACLs aren't the only problem, of course. But they are still a problem we need to address. Another idea: Does the _client_ machine know a mapping from id's to names for its own part of the namespace, possibly with id's distinct from the id's used on the server Implementation detail --- most clients will indeed know such a mapping, but they are not required to (in theory a client could legally map all remote ids to the "nobody" user and use the "ANONYMOUS@" pseudo-remote-id for all credentials checking). If so, then the client's kernel could map these id's to the proper names when needed, right? Yes. Exactly. You're getting the point --- it is possible for a client to manage the mapping for local uids in a sane manner, because the protocol doesn't impose any semantics on the utf/8 name other than the "id@domain" format. The local client can, if it chooses, use the numeric local uid/gid for the "id" part in all of its mappings, or it can use the username if there is a mechanism for obtaining that. The same lack of semantics on the "id" part which allows local clients to map their own local uid space any way they want, also prevents local clients from doing any useful parsing of remote ids. For remote ids, utf/8 is the only token available. It would then be completely transparent to applications running on the client machine which kinds of id's are used on the wire for remote mounted filesystems. Traversing filesystem mount points would be transparent, too. ACLs could be set across different types of remote filesystems (provided that the ACL systems supported are compatible, which is sort of hypothetical at the moment). Indeed. On the other hand, it wouldn't be possible to grant permissions to users from different realms through that mechanism... Indeed. That's what I've been saying all along. The "name family" part of the attribute API I proposed allows you to use local uids even on the ATR_NFSV4ACL ACL family, so that the type of local uid-to-id mapping you describe can be performed transparently even when we are specifying NFSv4 ACL semantics. However, for setting remote ACL rights, we still need to be able to specify ids in terms of utf/8 too. My API deals with this. It lets you work purely in terms of uids where the local implementation can deal with that, but also allows you to grant rights to "foreign" users. [...] IMHO there isn't really such a thing as NFSv4 ACLs. There are SMBFS ACLs, AFS ACLs, Posix ACLs, but no NTFSv4 ACLs. NFSv4 just provides a common format for representing different variants of ACLs, but no semantics. Actually, NFSv4 defines interpretation order, inheritance rules, default ACLs, directory and non-directory ACEs and all the other semantics, perfectly unambiguously. NFSv4 ACLs do exist, I'm afraid. Ald you are right again. That't what comes from skimming parts of specification. My apologies. NFSv4 indeed specifies yet another variant of ACLs. Yep. In fact, it defines a richer environment than POSIX. However, I _think_ that for any POSIX ACL, you can define an NFSv4 list which is equivalent in all details (although the reverse is definitely not true). So, it should be possible for even an NFSv4 client implementation to accept an ATR_POSIXACL request, and for it to construct an appropriate ACL to pass to the server. XFS also supports Posix 1003.1e ACLs, so the interface to XFS ACLs and ext2 ACLs hopefully will be identical. NFSv4 and AFS have different requirements. Yep. So, in theory we can accept POSIX ACLs whether the underlying filesystem is NFSv4, ext2+acls, or XFS. However, _if_ the filesystem is NFSv4, then there is some required functionality which we cannot support without a richer API. This is exactly why we need a versioned API. If all the user wants to do is to set an ACL which grants access rights to a couple of other local users, then the ATR_POSIXACL family can be used and the request will Just Work, regardless of the underlying filesystem (assuming that the implementation has bothered to
Re: [PROPOSAL] Extended attributes for Posix security extensions
On Sat, 28 Oct 2000, Daniel Phillips wrote:
"Stephen C. Tweedie" wrote:
On Fri, Oct 27, 2000 at 10:46:26AM +0200, Andreas Gruenbacher wrote:
Imagine if the kernel did store
"[EMAIL PROTECTED]" on ACLs on the filesystem. When an access control
decision needs to be done, the kernel simply has no idea about what
"[EMAIL PROTECTED]" means.
The VFS doesn't, but the filesystem does. In NFSv4, what happens at
the moment is that the kernel says "I don't know who the local user
is" and asks a local GSS daemon to do a kerberos authentication on the
user. Once that is complete, both the client and the server have an
authenticated and secure ID for the user of the form "username@REALM".
Since we have 32 bits worth of UID and GID now, why can't we create a
temporary UID at this point? Each unique ACL would be assigned a unique
GID and the temporary UID would belong to some appropriate set of
groups. This is such an obvious idea that I assume it must have been
discussed and rejected, but why?
I guess I meanwhile understand the purpose of "[EMAIL PROTECTED]"
identifiers (thanks Stephen, that was something I badly needed to catch up
with). The point seems to be not to have to mangle all user/group
identifiers into integers. A single uid/gid based user database doesn't
scale up to the size of the Internet.
"u@d" identifiers are passed in NFS requests to the NFS server. The server
verifies the authenticity of the request and identity, and uses the "u@d"
identifier directly to decide whether access is granted or not. In ACLs on
the filesystem, the same "u@d" identifiers are stored and compared against
the requests.
Translating all "u@d" identifiers into uid's/gid's would bring back the
same scalability problems the approach tries to get rid of.
I have my serious doubts how this could be implemented efficiently over
today's filesystems, though.
On plain-old ext2, uid's/gid's are used to identify file owners and owning
groups. What would one do with these id's in combination with "u@d"
identifiers? Some mechanism to translate from numeric id's to "u@d"
identifiers would be needed, but that's not possible entirely within the
kernel. Interactions with userspace daemons are slow and much less secure
than in-kernel mechanisms.
Also, do you store all identifiers known locally by id? How would changes
to the local user database affect the filesystem? Do you store both "u@d"
and uid's for all files? How about conflicts between namespaces? You would
also need to store the "u@d" and "g@d" identifiers of a file's owner and
owning group. (EA's seem a good mechanism for storing such complementary
information, but that observation is by far not enough to make it work.)
Which ACL semantics should NFS supporting ACLs implement? Should this be
Posix 1003.1e ACLs? The NFS protocol supports virtually all variants of
ACLs, but doesn't specify any semantics.
How do you ensure filesystem access checks are still blazingly fast?
Remember, for opening a file all the permissions along the path leading to
that file need to be checked. String comparisons ("u@g") seem quite
problematic.
These are simply too many questions for a straightforward implementation.
So I tend to think we should as a first step try to get plain Posix
1003.1e ACL's into the mainstream kernel without all those extensions, and
try to gain some more experience. That alone would bring Linux much closer
to large scale / trusted operating system. Paired with filesystem
capabilities support, Linux would get much "sexier", and more serious as
well.
Meanwhile, somebody will probably come along with many answers to the
other scalability problem. Of course, we could try to come up with the
perfect system first, and realize that later. That's surely not the most
effective approach IMHO.
Comments welcome, of course...
Cheers,
Andreas.
Andreas Gruenbacher, [EMAIL PROTECTED]
Contact information: http://www.bestbits.at/~ag/
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
Re: [PROPOSAL] Extended attributes for Posix security extensions
On Sat, 28 Oct 2000, Stephen C. Tweedie wrote: Hi, On Sat, Oct 28, 2000 at 05:17:11PM +0200, Andreas Gruenbacher wrote: On Sat, 28 Oct 2000, Daniel Phillips wrote: I guess I meanwhile understand the purpose of "[EMAIL PROTECTED]" identifiers (thanks Stephen, that was something I badly needed to catch up with). The point seems to be not to have to mangle all user/group identifiers into integers. A single uid/gid based user database doesn't scale up to the size of the Internet. No, that misses the point. It's not about scaling as much as it is about generalising credentials. Oh. If you have a centralised storage server, you may have several existing networks connect to that server and those networks may all already have their own uid/gid namespaces (or, in fact, they may use a totally different namespace such as NT SIDs). uid 777 on my network might be a completely different user to uid 777 on your network, but we might both want to share a storage server and I might want to grant different access rights to the two separate users who happen to have the same uids on their local systems. "u@d" identifiers are passed in NFS requests to the NFS server. The server verifies the authenticity of the request and identity, and uses the "u@d" identifier directly to decide whether access is granted or not. In ACLs on the filesystem, the same "u@d" identifiers are stored and compared against the requests. Translating all "u@d" identifiers into uid's/gid's would bring back the same scalability problems the approach tries to get rid of. Not at all --- it is quite easy to believe that such a networked storage server could easily represent all of its distributed users in some private, local 32-bit uid/gid namespace internally. That's an implementation detail. It is the communication between different authentication realms which needs the extra abstraction, because the local namespaces in each realm just don't mean anything in the other realms. So what you're saying is each user and group that is ever referred to in a Posix ACL always has an id associated with it. The machine would just do some remapping, similar to ugidd. In that case I fail to see the original problem, as each Posix ACL can already be represented using the format that I'm using in the kernel (linux/posix_acl.h:posix_acl_t) right now. On plain-old ext2, uid's/gid's are used to identify file owners and owning groups. What would one do with these id's in combination with "u@d" identifiers? Some mechanism to translate from numeric id's to "u@d" identifiers would be needed, but that's not possible entirely within the kernel. Interactions with userspace daemons are slow and much less secure than in-kernel mechanisms. Sure, but we don't have any choice. NFSv4 mandates this mechanism, and requires that we support Kerberos authentication, which as you point out really ought to be done in user space. That is already working in the NFSv4 code. The kernel doesn't have to know about any other credentials scheme --- it just uses the same old uid/gid combinations. However, the initial authentication pass between client and server is done in user land at the kernel's request, and is done using the Kerberos namespace. The question at hand is the API, not the implementation. We need an API which lets us manage POSIX ACLs, and which also lets us manage NFSv4 ACLs. IMHO there isn't really such a thing as NFSv4 ACLs. There are SMBFS ACLs, AFS ACLs, Posix ACLs, but no NTFSv4 ACLs. NFSv4 just provides a common format for representing different variants of ACLs, but no semantics. So a Posix ACL still stays a Posix ACL even if represented in NTFSv4 format. So does an SMBFS ACL, etc. (I'm _not_ saying this to annoy you, I'm just trying to nail down a few things to eliminate further misunderstandings.) When an NFSv4 request to set/retrieve a Posix ACL arrives, the "[EMAIL PROTECTED]" identifiers can be translated into uid's/gid's. From that point on, the data structures defined in include/linux/posix_acl.h in my patch are perfectly suitable already. If such a request arrives in userspace, then the "[EMAIL PROTECTED]" identifiers can be translated into the respective id's before passing the beast to the kernel. No problem here, either. If your vision is to design a super ACL system for Linux that covers all ACL implementations out there, then I'm afraid my opinion is that such an attempt is in vein. Try to unify Posix 1003.1e ACLs and SMBFS (NT) ACLs. It's hopeless. The result would be so complex it wouldn't be usable by the average sysadmin anymore. The ACL patch limits itself to support Posix 1003.1e draft standard 17 ACLs; nothing more and nothing less. I'm aware that there are many features that would be nice to have. This is all possible in the future, but extending the set of permissions supported is extremely brittle. The people in the 1003.1e working group were no fools.
Re: [PROPOSAL] Extended attributes for Posix security extensions
Chris Mason wrote: --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? Specifying ACL invokes the ACL method on all I/O to that non-stream attribute. 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. The specified ACL method does it, however you want it. 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. Yes, it needs an ACL method. -chris - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [PROPOSAL] Extended attributes for Posix security extensions
On Thu, 26 Oct 2000, Craig Ruff wrote: On Thu, Oct 26, 2000 at 11:02:52PM +0200, Andreas Gruenbacher wrote: Sorry, but I think the root namespace is a serious misdesign. The root user shouldn't be treated specially at all. In a system that fully supports capabilities, it's actually possible for root to have no permissions whatsoever. Allowing root to manipulate EAs of files effectively makes root omnipotent again (by manipulating the capabilities of files, etc.) How do you prevent users from using EA keys that are used for essential system services (e.g. HSM support)? By not giving them access to that part of the EA namespace that they shouldn't have access to. Are you going to require that a default EA for these keys that is automatically propagated to all new file/directories be setup by the admin before file system use? In this case, it would seem that you would need to attach ACLs to these EAs to prevent the user from manipulating or deleting them. What happens if the admin needs to convert an existing file system to support an HSM? No, not at all. System security objects like Posix 1003.1e ACLs and Capabilities (and others, too) have clearly defined semantics. To make the case for Posix ACLs: - Everybody who is allowed to search a directory may also read the ACLs of the files in that directory. - Only the file owner or a user capable of CAP_FOWNER may change the ACLs of files. - In addition, nobody, ever, should be able to set an ACL to an invalid value, even if they are allowed to set the ACL. This is exactly the policy the kernel must enforce. Nothing more, nothing less. Creating additional paths to manipulating ACLs (say, by allowing ACLs implemented as EAs to be manipulated directly through the EA interface in an incompatible way) is _very_ evil. It's just as evil if the user doing the manipulations is the superuser. On the other hand, even if you had separate ACL syscalls, those syscalls would need to enforce that policy as well. So my approach is to enforce the policy in the EA interface directly (I'm using EA handlers in the kernel for that right now). That way, the EA interface can be used also for manipulating ACLs, so no additional interfaces are needed. All EAs can be manipulated through the same interface, so things stay much simpler. Even backing up / restoring the EAs of a file isn't difficult through that interface, without opening any security holes. Andreas Andreas Gruenbacher, [EMAIL PROTECTED] Contact information: http://www.bestbits.at/~ag/ - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [PROPOSAL] Extended attributes for Posix security extensions
On Thu, 26 Oct 2000, Stephen C. Tweedie wrote: Hi, On Thu, Oct 26, 2000 at 10:21:22PM +0200, Andreas Gruenbacher wrote: I'm aware of that problem. That's why I think test-and-set is less painfull, although it involves more overhead. OK, I'm convinced. I would like to research whether a versioning interface (to ensure consistent updates) is possible at all, so I will take a closer look at the NFSv4 spec. I still think that attribute families need a different encoding so that we can be really unambiguous about ACL setting and about the application's expectations of inheritance, atomicity etc. I don't agree with you here. For ACLs that really require editing / inserting / removing ACL entries, the extended attributes interface just doesn't fit. A different interface to the kernel is needed for those cases (different system calls, whatever). I already proposed an API which allows you to edit individual ACLs or to replace the entire chain, in an implementation-independent manner. And yes, it wasn't an EA API, but it could be used for both. I also _really_ don't like different EA families to have different semantics (some with atomicity some not, some with ordering some not, etc.) That's plain ugly with no guarantees that this more powerful interface will provide what's needed. Think about the read(2) system call. Is it atomic? Well, yes for datagram sockets, no for streams, depends on the read size for pipes... and it's blocking or not depending on the type of the file and the fcntl() flags you may or may not have set on it. You have the same operations on files, and usually, you get to choose the semantics yourself (as the user of the API). In the EA case, the semantics would mostly be enforced by the kernel, depending on the EA name. This is what we are talking about here --- an API which can address different types of object in a uniform manner. The semantics are not in the API --- they are in the object being addressed, and are hence implied by the name you supply to identify the object. That's a perfectly clean way of doing things which is already used extensively in Unix. If you go the separate-syscall approach, then you still don't fix the problem, because: 1) you still have to deal with the fact that different filesystems will have different semantics and so you need to add versioning/ naming control to your API anyway; and 2) the moment somebody comes up with a _new_ attribute that you hadn't thought of, you need to resort to new syscalls or you can't access them. The moment somebody comes up with a new system EA, that somebody will have to implement the right policy in the kernel (as an EA handler in my implementation). System EAs are not just EAs that happen to have a different name. Manipulations of them are tightly controlled by the kernel. User EAs have clearly defined, consistent semantics across the user part of the namespace, so adding new user EAs of course does not require anything like that. OK, but we _still_ need the namespace interface for authentication tokens if we are to deal with things like NFSv4. That particular problem isn't going to go away, unfortunately. Could you please explain that to me some more? In NFSv4, authentication tokens are UTF/8 character strings, not Unix uids. You can map a Unix ID to an NFSv4 name quite easily: it would come out as "[EMAIL PROTECTED]" or "[EMAIL PROTECTED]". However, you _also_ want to be able to deal with remote users who do not have local unix uids, and there simply isn't a mapping between uids and those remote names. So, any ACL API capable of dealing with NFS ACLs must not only provide for uids, it must also be able to accept other tokens (UTF/8 strings in this case, but also NT SIDs in the case of SMB ACLs) if the user demands it. There seems to be a fundamental problem here. You are talking about manipulating ACLs through the kernel interface that have no meaning to the kernel itself. The kernel just doesn't know anything about "[EMAIL PROTECTED]", not even for the local domain. The kernel also can't even translate from username to uid. It knows only about uid's; that's what access control decisions are based on. The Posix ACLs I have implemented are meaningful to the kernel, so the kernel can deal with them. I have to do some backgroud reading on NFSv4, but right now I really don't know what the kernel could ever do with "[EMAIL PROTECTED]" other than pass that on in an NFS RPC or such. Imagine if the kernel did store "[EMAIL PROTECTED]" on ACLs on the filesystem. When an access control decision needs to be done, the kernel simply has no idea about what "[EMAIL PROTECTED]" means. Yes, and my position is just the opposite. I believe in keeping the EA interface simple What's so complex about "name=value" pairs as provided by the ATR_USER family? In the API I proposed, ATR_USER _is_ the basic named attribute API.
Re: [Openxdsm-devel] Re: [PROPOSAL] Extended attributes for Posix security extensions
Hi, On Fri, Oct 27, 2000 at 01:11:44AM +0200, Ragnar Kj?rstad wrote: On Fri, Oct 27, 2000 at 12:24:19AM +0200, Andreas Gruenbacher wrote: I don't think so. My suggestion would be this: All user EAs are prefixed with "user." when passed to the kernel. The prefix is not actually stored on the filesystem. Likewise, all root EAs are prefixed with "root.". If they are to be "stripped" of by the kernel, would it not be better to keep it in a seperate field? That would be my preference, but I'm happy either way as long as we can pass in the namespace information in some way. It is always a prefix and a name, right? A hirarchie is out of the question? (A hirarchie can of course not be represented in two fields) Why would you want a hierarchy? I'm not against it in principle, but I'm definitely against complicating the interface without having any good reason for doing so. Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [PROPOSAL] Extended attributes for Posix security extensions
Hi, On Fri, Oct 27, 2000 at 10:46:26AM +0200, Andreas Gruenbacher wrote: On Thu, Oct 26, 2000 at 10:21:22PM +0200, Andreas Gruenbacher wrote: I'm aware of that problem. That's why I think test-and-set is less painfull, although it involves more overhead. OK, I'm convinced. I would like to research whether a versioning interface (to ensure consistent updates) is possible at all, so I will take a closer look at the NFSv4 spec. OK. I also _really_ don't like different EA families to have different semantics Think about the read(2) system call. Is it atomic? Well, yes for datagram sockets, no for streams, depends on the read size for pipes... and it's blocking or not depending on the type of the file and the fcntl() flags you may or may not have set on it. You have the same operations on files, and usually, you get to choose the semantics yourself (as the user of the API). In the EA case, the semantics would mostly be enforced by the kernel, depending on the EA name. No --- in both cases it's a mix of the two. For regular files, you get zero choice as a user. For sockets, you get some choice --- O_NONBLOCK, for example --- but other choices are forced upon you (eg. atomicity is not an option you can enable or disable arbitrarily). In the EA case, too, you get to choose which semantics you want when you specify the namespace (and hence specify the object you are accessing); the rest is forced upon you from there. 2) the moment somebody comes up with a _new_ attribute that you hadn't thought of, you need to resort to new syscalls or you can't access them. The moment somebody comes up with a new system EA, that somebody will have to implement the right policy in the kernel (as an EA handler in my implementation). System EAs are not just EAs that happen to have a different name. Manipulations of them are tightly controlled by the kernel. You keep talking about them as if they are all implemented through your EA handler. If you take that as your starting point, then of _course_ you'll end up with such an API. What about filesystems which implement MAC labels and/or ACLs, but not named attributes? Why should the application coerce the ACL into an artificial attribute, just for the filesystem to have to unpick it again? In NFSv4, authentication tokens are UTF/8 character strings, not Unix uids. You can map a Unix ID to an NFSv4 name quite easily: it would come out as "[EMAIL PROTECTED]" or "[EMAIL PROTECTED]". However, you _also_ want to be able to deal with remote users who do not have local unix uids, and there simply isn't a mapping between uids and those remote names. So, any ACL API capable of dealing with NFS ACLs must not only provide for uids, it must also be able to accept other tokens (UTF/8 strings in this case, but also NT SIDs in the case of SMB ACLs) if the user demands it. There seems to be a fundamental problem here. You are talking about manipulating ACLs through the kernel interface that have no meaning to the kernel itself. The kernel just doesn't know anything about "[EMAIL PROTECTED]", not even for the local domain. The kernel also can't even translate from username to uid. It knows only about uid's; that's what access control decisions are based on. The Posix ACLs I have implemented are meaningful to the kernel, so the kernel can deal with them. That's simply not true. We have code to prove it: NFSv4 and AFS already work on Linux. The trick, of course, is that the names involved are only meaningful to the filesystem itself, not to the rest of the kernel --- but that's fine if what we are producing is an API to the filesystem. On a distributed filesystem, you *HAVE* to be able to specify access rights for remote users. Think about a big NetApps server box connected to a number of different departments in an organisation. I may have a file owned by my account "sct@development", and I may want to make it readable to "joe@support". These names are meaningful to the filesystem. If they have no meaning to the local kernel, then that just means that ACEs using those names will never be applied to local users. It is still imperative that the local user has a way to set rights for remote users. I have to do some backgroud reading on NFSv4, but right now I really don't know what the kernel could ever do with "[EMAIL PROTECTED]" other than pass that on in an NFS RPC or such. Imagine if the kernel did store "[EMAIL PROTECTED]" on ACLs on the filesystem. When an access control decision needs to be done, the kernel simply has no idea about what "[EMAIL PROTECTED]" means. The VFS doesn't, but the filesystem does. In NFSv4, what happens at the moment is that the kernel says "I don't know who the local user is" and asks a local GSS daemon to do a kerberos authentication on the user. Once that is complete, both the client and the server have an authenticated and secure ID for the user of the
Re: [PROPOSAL] Extended attributes for Posix security extensions
Curtis Anderson wrote: It all depends on how optional things are, and what differences an unmodified app sees. IMHO, "none" is the right answer in this case. Part of my believing that directory-hack stream-style attributes are not good is that I don't know how to do them without making visible changes in the semantics of existing objects. Proposing examples on how to make these extensions transparently to existing apps would help. Could you please give one or two examples of existing objects whose semantics would be changed by a directory-hack stream-style attributes? I'll try to counter, and if I fail then at least I'll have a concrete reason to give up on the idea. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
RE: [Openxdsm-devel] Re: [PROPOSAL] Extended attributes for Posix security extensions
So what about "tar"? Stephen has been banging the drum about a unified API for ACL's and I think good things came out of that discussion. Building an archive of a file system with ACL's or other EA's and untarring it on a different file system/system is at present a mess and quite dangerous. I think DEC had a clever way of dealing with it, it put a file twice in the tar archive, the first time it held the content of the ACL, the second time the name appeared it held the content of the file. So unless tar crashed in the middle, you'd get a somewhat sensible unpacking behaviour. I think that a families approach will give us the best chances of converting many different EA's sensibly from one file system to another when we tar it up and unpack it again. Comments anyone? - Peter - - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [PROPOSAL] Extended attributes for Posix security extensions
On Wed, Oct 25, 2000 at 02:50:32AM +0200, Andreas Gruenbacher wrote: On Tue, 24 Oct 2000, Christoph Hellwig wrote: [...] But the ACL implementation is not generic enough, IMHO. The ACL implementation is Posix 1003.1e draft standard 17 compliant. AFAIK neither of the other ACL implementations (Solaris, Irix, FreBSD) can claim that. Yep. That's completly right. The only problem is - even if ext2 with your patches maps ACLs to EAs there are filesystems that do not. IMHO iw would be better use separate syscalls for ACLs and EAs. So a filesystem like NFSv4 could use the same ACL tools (yours) and syscalls. 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]
Re: [PROPOSAL] Extended attributes for Posix security extensions
--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]
Re: [Openxdsm-devel] Re: [PROPOSAL] Extended attributes for Posix security extensions
On Thu, Oct 26, 2000 at 04:14:06PM +0100, Stephen C. Tweedie wrote: Either way, the point stands -- building APIs on assumptions about implementation details (in this case, that ACLs are built on top of EAs) is a bad thing. True enough. The interface I proposed doesn't enforce the implementation though (I guess I was unclear about this). Sure, but it makes an artificial distinction where there isn't one. There isn't any difference, really, between ACLs and named attributes --- they are just two examples from a whole continuum which includes attributes as mundane as filesize through MAC labels, compression state, DMAPI attributes and others. Singling out ACLs for special treatment seems bizarre --- my gut feeling is that the API needs to be able to deal with other forms of structured attribute in the future just as cleanly as it deals with ACLs, so giving ACLs its own special syscall seems odd. I think each system attribute will need it's own API; * A different API is probably better suitable for the user this can of course be handled in libc, but in some cases * different parts of the EA have different security policies If I understand Andreas correctly, his intention is to store _all_ ACL data in one EA. The ACL interface will update this one EA with new data; handling all the ordering and so on. As far as the filesystem is concerned, the "$ACL" is just another chunk of data it needs to store - it has no knowledge about what it is. In the case of XDSM there is already a set API for the user. For practical reasons, the userspace-kernel API will also be a XDSM specific one. All openXDSM need from the filesystem is some way to store opaque metadata. I guess I'm saying ACL and EA should be seperate interfaces because the users should not have to know they are related. In some filesystems maybe they're not - in others maybe EA is implemented using ACL. The user doesn't care. -- Ragnar Kjørstad Big Storage - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [PROPOSAL] Extended attributes for Posix security extensions
Curtis Anderson wrote: So it's not clear how you reached to the conclusion that directories shouldn't be pressed into service as compound files. I'm sure you have a reason, but it wasn't revealed here! It's an aesthetics argument. There are no new features in a directory-based streams-style attribute mechanism over basic filesystem semantics. It would be bad to confuse things by trying to say that this is "new" or "different" when it is not. The argument is also recursive, although I didn't bring that out in my email. Once I have such heavyweight streams-style attributes, maybe I need to store some additional pieces of information about that stream. For example, if I have an audio clip attribute where I say "My name is Linus and my OS is called Linux", I still need to know the encoding format and bit rates to reproduce the accent correctly. I've now claimed I need attributes of attributes, possibly with ACLs, timestamps, etc, etc. This is really just a call for hierarchically organized information, ie: directories and subdirectories. Which is again, what we have now. The problem with streams-style attributes comes from stepping onto the slippery slope of trying to put too much generality into it. I chose the block-access style of API so that there would be no temptation to start down that slope. Could you please produce a more substantive argument. :-) You are making an excellent argument in favor of doing exactly what you seem to oppose. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [PROPOSAL] Extended attributes for Posix security extensions
On Thu, 26 Oct 2000 [EMAIL PROTECTED] wrote: For an existing API (which I am not proposing be taken as is) take a look at the xfs man pages here: http://oss.sgi.com/projects/xfs/manpages.html Sorry, but I think the root namespace is a serious misdesign. The root user shouldn't be treated specially at all. In a system that fully supports capabilities, it's actually possible for root to have no permissions whatsoever. Allowing root to manipulate EAs of files effectively makes root omnipotent again (by manipulating the capabilities of files, etc.) However, there should be a separate namespace for system related attributes like ACL, CAP, MAC for which the kernel determines whether an access is granted or not. No user, ever, is able to override the security policy of the kernel in this namespace. Also, the kernel doesn't only rule whether an access is granted, but also which values the EA may assume. Also, XFS has two separate namespaces. Merging them (and keeping the namespace information in a name prefix) would be a good thing as it would simplify the interface. Attributes from multiple namespaces would be brought into context by their name only. Otherwise, [1342]acl and [4742]acl might look very similar, but indeed they would describe entirely different things. Here's another manpage pointer to Tru64 "property lists": http://www.tru64unix.compaq.com/faqs/publications/base_doc/DOCUMENTATION/V50_HTML/MAN/MAN4/0200.HTM And to FreeBSD: http://www.FreeBSD.org/cgi/man.cgi?query=extattr Thanks, Andreas. Andreas Gruenbacher, [EMAIL PROTECTED] Contact information: http://www.bestbits.at/~ag/ - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [PROPOSAL] Extended attributes for Posix security extensions
Andreas Gruenbacher wrote: On Thu, 26 Oct 2000 [EMAIL PROTECTED] wrote: For an existing API (which I am not proposing be taken as is) take a look at the xfs man pages here: http://oss.sgi.com/projects/xfs/manpages.html Sorry, but I think the root namespace is a serious misdesign. The root user shouldn't be treated specially at all. In a system that fully supports capabilities, it's actually possible for root to have no permissions whatsoever. Allowing root to manipulate EAs of files effectively makes root omnipotent again (by manipulating the capabilities of files, etc.) Keep in mind that XFS EA's were designed before ACLs made it into IRIX. Having said that, I agree with you that the root namespace does not mix well with ACLs. I like the idea of user, system, and trusted namespaces. Also, XFS has two separate namespaces. Merging them (and keeping the namespace information in a name prefix) would be a good thing as it would simplify the interface. Attributes from multiple namespaces would be brought into context by their name only. Otherwise, [1342]acl and [4742]acl might look very similar, but indeed they would describe entirely different things. Even though it makes life more difficult, I like the idea of very separate namespaces for separate types of things. The worst case is when a user application wants to create an attribute named "foo" but that name has already been used by a system or trusted entity. Putting error recovery algorithms inside applications to resolve attribute namespace collisions is ugly and the API should be set up to avoid them if possible. Thanks, Curtis - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [Openxdsm-devel] Re: [PROPOSAL] Extended attributes for Posix security extensions
On Fri, Oct 27, 2000 at 12:24:19AM +0200, Andreas Gruenbacher wrote: I don't think so. My suggestion would be this: All user EAs are prefixed with "user." when passed to the kernel. The prefix is not actually stored on the filesystem. Likewise, all root EAs are prefixed with "root.". If they are to be "stripped" of by the kernel, would it not be better to keep it in a seperate field? It is always a prefix and a name, right? A hirarchie is out of the question? (A hirarchie can of course not be represented in two fields) -- Ragnar Kjørstad Big Storage - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [PROPOSAL] Extended attributes for Posix security extensions
Curtis Anderson wrote: The problem with streams-style attributes comes from stepping onto the slippery slope of trying to put too much generality into it. I chose the block-access style of API so that there would be no temptation to start down that slope. I understand you right up until this. I just don't get it. If you extend the functionality of files and directories so that attributes are not needed, this is goodness, right? I sure think it is the right approach. We should just decompose carefully what functionality is provided by attributes that files and directories lack, and one feature at a time add that capability to files and directories as separate optional features. I would really like to keep a syntax that lends itself to a set theoretic approach so that I can one feature at a time make our FS into a set theoretic database. That is my hidden agenda here: if you clutter the basic concepts of filesystems it makes it more work to do a clean extension of filesystems into my pet novel theory for database semantics that is substantially upwardly compatible with filesystems. I REALLY want the more general approach for this reason. Hans - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [PROPOSAL] Extended attributes for Posix security extensions
Daniel Phillips wrote: Curtis Anderson wrote: For example, "mv" will devolve to "cp" when the source and destination filesystems are different. So "mv" will preserve attributes for some operations, and will drop them on the floor for others. Unexpected by the average user, and therefore bad. But why should cp drop attributes? I can see cat foo bar dropping attributes, but not cp. If it were updated to support EA's, it would not drop them. It is an example of a program that makes assumptions about the "shape" of a file (ie: not having EA's), and that would need to be modified. I don't know of a way to get the attribute copying to happen automagically, especially given that sometimes you want them copied and sometimes not, so I believe that the utility's code needs to be modified. It was given as an example in support of my assertion that adding EA's in a consistent fashion to an OS is not a trivial task. In order for users to not get surprises when they sometimes go away, all of the tools in the system need to be examined and possibly updated. The scale of the problem is what makes it a problem, not the task of updating any single utility. Daniel Phillips wrote: Curtis Anderson wrote: It's an aesthetics argument. There are no new features in a directory-based streams-style attribute mechanism over basic filesystem semantics. It would be bad to confuse things by trying to say that this is "new" or "different" when it is not. [snip] The problem with streams-style attributes comes from stepping onto the slippery slope of trying to put too much generality into it. I chose the block-access style of API so that there would be no temptation to start down that slope. Could you please produce a more substantive argument. :-) You are making an excellent argument in favor of doing exactly what you seem to oppose. I think it comes back to the aesthetics of it. I don't like the idea of taking something we have now and that we all understand and trying to put a new name on it and pretend it is new. I'm looking for things that have new semantics or new access methods, things that may spark new ways of doing things. Thanks, Curtis - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [PROPOSAL] Extended attributes for Posix security extensions
CCed to openxdsm because we need extended attributes and Hans Reiser because I know he has comments but didn't reply to your mail. On Sun, Oct 22, 2000 at 04:23:53PM +0200, Andreas Gruenbacher wrote: Hello, This is a proposal to add extended attributes to the Linux kernel. Extended attributes are name/value pairs associated with inodes. A patch implementing extended attribute system calls, the VFS interface, and code for the ext2 filesystem is available. All material is GPL and/or LGPL licensed. The core implementation is pretty stable since months. Did you read the thread on l-k regarding a common interface for accessing extended attributes (much like NTFS streams)? New to the code base is a mechanism for sharing extended attribute blocks among inodes on the ext2 filesystem. This is a significant optimization. The block sharing code might still contain bugs. It can be deactivated at kernel compile time. This is just an optimization within the filesystem transparent to VFS and userspace, right? So each filesystem can choose if to do this optimization, and how - for example, for many filesystems it would make sence to make this a more general optimization; compressing any common "objects" using the same algorithm. What about inheritence for extended attributes? With this code, there are two options: * Just setting the attribute for the directory and all subdirectories (It get's compressed anyway...) (not really inheritence though) * Implement inheritence in the layers using the attributes, e.g. ACL I don't know how much need there is for inheritence here, but if a lot of attributes will need it I think it should be supported in the interface instead. (though hardlinks really make this hard) CURRENT USES A complete and close to production quality implementation of POSIX-like access control lists, implemented on top of extended attributes, exists. This patch is maintained to be in sync with the extended attributes patch. Andrew Morgan has some code against an earlier version of the extended attributes patch that implements filesystem capabilities. This patch is out of date at the moment. HSMs also usually need extended attributes to store data in. A common interface to extended attributes on all linux filesystem is a requirement for being able to implement XDSM generally for linux. -- Ragnar Kjørstad Big Storage - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [PROPOSAL] Extended attributes for Posix security extensions
On Tue, 24 Oct 2000, Ragnar Kjørstad wrote: On Sun, Oct 22, 2000 at 04:23:53PM +0200, Andreas Gruenbacher wrote: Hello, This is a proposal to add extended attributes to the Linux kernel. Extended attributes are name/value pairs associated with inodes. A patch implementing extended attribute system calls, the VFS interface, and code for the ext2 filesystem is available. All material is GPL and/or LGPL licensed. The core implementation is pretty stable since months. Did you read the thread on l-k regarding a common interface for accessing extended attributes (much like NTFS streams)? I am aware of a recent thread about streams akin to a flamewar. If I recall correctly there were not many arguments applicable to extended attributes. I hope I made clear that streams and extended attributes are separate things. Streams are accessed using regular file semantics. Extended attributes are accessed atomically using stateless operations (no open--close). New to the code base is a mechanism for sharing extended attribute blocks among inodes on the ext2 filesystem. This is a significant optimization. The block sharing code might still contain bugs. It can be deactivated at kernel compile time. This is just an optimization within the filesystem transparent to VFS and userspace, right? Yes. The block sharing code is at the filesystem layer, completely transparent to the VFS. So each filesystem can choose if to do this optimization, and how - for example, for many filesystems it would make sence to make this a more general optimization; compressing any common "objects" using the same algorithm. What about inheritence for extended attributes? With this code, there are two options: * Just setting the attribute for the directory and all subdirectories (It get's compressed anyway...) (not really inheritence though) * Implement inheritence in the layers using the attributes, e.g. ACL I don't know how much need there is for inheritence here, but if a lot of attributes will need it I think it should be supported in the interface instead. (though hardlinks really make this hard) In UNIX like filesystems, permissions are associated with inodes. Inheritance based schemes tend to associate permissions with directory entries. There's an inherent conflict between the two. (Personally I prefer the inode based scheme.) For Posix like Access Control Lists at least I don't see how inheritance could possibly work out. All ideas I have seen so far seem to collapse at some point. I have discussed that with Vyacheslav Zavadsky (the "Linux Trustees guy") a long time ago without consensus. My conclusion was back then was Trustees don't scale up very well. Thanks, Andreas Andreas Gruenbacher, [EMAIL PROTECTED] Contact information: http://www.bestbits.at/~ag/ - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [Openxdsm-devel] Re: [PROPOSAL] Extended attributes for Posix security extensions
"Stephen C. Tweedie" wrote: Hi, On Tue, Oct 24, 2000 at 09:20:05AM +0200, Ragnar Kj?rstad wrote: I don't know how much need there is for inheritence here, but if a lot of attributes will need it I think it should be supported in the interface instead. (though hardlinks really make this hard) POSIX makes an unambiguous definition of inheritence --- inheritence is applied on file creation. Hard links only create a new directory entry, not a file, so the ACLs on the linked file don't change. Similar rules apply to rename. Basically, you don't want things like mv and ln to modify the ACLs on an existing file (although of course the ACLs on the directory containing the new dirent may change the effective permissions by removing the right to access the dirent in the first place). Cheers, Stephen I am not convinced that it is necessarily bad for mv and ln to change the permissions. I mean, they do that currently, why not allow it to happen for ACLs also? Hans - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [PROPOSAL] Extended attributes for Posix security extensions
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]
Re: [PROPOSAL] Extended attributes for Posix security extensions
Hi, On Wed, Oct 25, 2000 at 09:09:57AM -0700, Hans Reiser wrote: Why do you force the user to copy the data into the attrib structure, rather than letting him leave the data where it lies and simply specify the location to the kernel? In the first draft of the API put together, I did in fact leave the attributes intact and just referred to the buffers indirectly. However, that breaks for GETALL, where the application is giving the kernel a large buffer into which an unknown number of attributes may be written. It also breaks the old-value return from the SET functions if, for example, you are setting an ACL on a uid which already has more than one ACL entry. Basically, for returning an unknown number of items to user space, it's much cleaner just to let the kernel stuff all of the data into a single return buffer. We _could_ specify different data layouts for set and get, but that's ugly. Why do you treat attributes differently from files? Why is your interface specific to attributes rather than files generally with attributes being files with a particular name? Atomic updates. There are existing filesystems which have completely separate namespaces for block-attributes and for named streams. Named streams have proper file semantics, but block attributes do not --- they have a fixed maximum size and are read/written in one single go. Furthermore, for security applications (eg. ACLs) you really want the atomic update guarantees to be 100% failsafe in the kernel, and ideally you want atomic get-and-set. The extended attribute API was meant for situations where we are dealinng with these sorts of attributes, not for places where streams are more appropriate. Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [PROPOSAL] Extended attributes for Posix security extensions
"Stephen C. Tweedie" wrote: Hi, On Wed, Oct 25, 2000 at 09:09:57AM -0700, Hans Reiser wrote: Why do you force the user to copy the data into the attrib structure, rather than letting him leave the data where it lies and simply specify the location to the kernel? In the first draft of the API put together, I did in fact leave the attributes intact and just referred to the buffers indirectly. However, that breaks for GETALL, where the application is giving the kernel a large buffer into which an unknown number of attributes may be written. That is why I use a sequence of assignment statements in my proposal for a syntax. That allows you to leave in place the data, and assign multiple file contents to multiple locations in the process address space, or use a file descriptor to access the contents, as the user chooses. It also breaks the old-value return from the SET functions if, for example, you are setting an ACL on a uid which already has more than one ACL entry. Basically, for returning an unknown number of items to user space, it's much cleaner just to let the kernel stuff all of the data into a single return buffer. Do you see why I disagree on this? We _could_ specify different data layouts for set and get, but that's ugly. Why do you treat attributes differently from files? Why is your interface specific to attributes rather than files generally with attributes being files with a particular name? Atomic updates. You are saying we need a transaction syntax with a transaction start and a transaction end operator pair, yes? Let's stop being inferior to databases. this is something new, let's do it right. There are existing filesystems which have completely separate namespaces for block-attributes and for named streams. Named streams have proper file semantics, but block attributes do not --- they have a fixed maximum size and are read/written in one single go. So you need an EINCOMPLETE_IO or some such, yes? procfs has the same problem, let's solve it orthogonally to this discussion. Furthermore, for security applications (eg. ACLs) you really want the atomic update guarantees to be 100% failsafe in the kernel, and ideally you want atomic get-and-set. The extended attribute API was meant for situations where we are dealinng with these sorts of attributes, not for places where streams are more appropriate. You can access as a stream or as an atomic unit, just specify it or constrain it, but that should be an orthogonal feature. Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [Openxdsm-devel] Re: [PROPOSAL] Extended attributes for Posix security extensions
Hi, On Wed, Oct 25, 2000 at 08:45:28AM -0700, Hans Reiser wrote: Extended attributes should be accessed by an interface that accesses them as files with a particular name. That is a good goal, but it breaks down in some cases. There already exist filesystems where named streams and named atomic attributes both already exist. We need to differentiate between them. There already exist attributes which cannot be made into a stream, because we simply don't have access to the raw bits of the attribute --- for example, ACLs on networked filesystems. There exist attribute streams where the user may have write access to some sections but not others --- again, ACLs spring to mind. There exist attribute streams where we want type information to be passed: the example of POSIX ACLs using authentication tokens other than uid/gid is a good example, as Samba really wants to be able to set up native ACLs with NT SIDs as identifiers. Accessing extended attributes as if they were files is a useful API, but there are structured attributes where we really need better control over what is going on. I'm not saying that we can't expose the extended attributes as files, too --- just that such an API isn't sufficient for all cases. Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
