On Tue, 24 Oct 2000, Stephen C. Tweedie wrote:
> Hi,
>
> On Sun, Oct 22, 2000 at 04:23:53PM +0200, Andreas Gruenbacher wrote:
> >
> > This is a proposal to add extended attributes to the Linux kernel.
> > Extended attributes are name/value pairs associated with inodes.
>
> What timing --- we had a long discussion (actually, several!) about
> this very topic at the Miami storage workshop last week.
>
> One of the main goals we had in getting people together to talk about
> extended attributes in general, and ACLs in particular, was to deal
> with the API issues cleanly. In particular, we really want the API to
> be at the same time:
>
> * General enough to deal with all of the existing,
> mutually-incompatible semantics for ACLs and attributes; and
>
> * Specific enough to define the requested semantics unambiguously
> for any one given implementation of the underlying attributes.
>
> These points are really important. We have people wanting to add ACL
> support to ext2 in a manner which Samba can use --- can we do POSIX
> ACLs with NT SID identifiers rather than with unix user ids? If we
> mount an NTFS filesystem, it will have native ACLs on disk. How does
> the API speficy that we want NT semantics, not POSIX semantics, for a
> given request?
The Linux kernel implements the POSIX model of security, including uid's
and gid's etc. The in-kernel representation of a user's identity will
probably always be a uid. Posix ACLs and other security extensions
(1003.1e draft standard 17) fit into that model.
NTFS ACLs won't. The only way I can see NTFS could work on Linux systems
would be to provide a mapping between Linux and NT concepts (like SID's)
at the interfaces to the kernel.
Note that I have so far always referred to Posix 1003.1e draft standard 17
ACLs. Also, I started out mentioning Posix ACLs with the intention to
document that there are real-world uses for extended attributes, and to
make the case for different types of extended attributes (user and system
in my proposal). I did not really intend to discuss ACL issues at this
point, but here we are.
Note that I'm referring to Posix 103.1e DS17 ACLs only. Other ACL systems
very probably will require a completely different representation, probably
mirrored as separate extended attributes.
I agree that ACLs and EAs could be split completely (having separate
system calls for EAs and ACLs). My reasoning for manipulating ACLs through
the EA system calls directly is that ACLs need to be passed between the
kernel and user space in some flattened format eventually. By choosing
this format as I did, some filesystems may choose to use it directly,
while others may want to transform it into something completely different.
In the kernel I could also imagine having separate VFS inode operations
for Posix ACLs, so that filesystems don't have to go through the EA
conversion.
Stephen, I got the impression that you were thinking about updating
individual ACL entries in the kernel would need to be an atomic operation.
Let me try to clarify. Posix ACLs consist of a number of ACL entries. ACLs
are always retrieved and set entirely. If individual entries need to be
changed, that amounts to retrieving the whole ACL, changing the entries,
and replacing the old ACL with the updated one.
I would really appreciate if we could try to focus on EAs for a while, and
address the ACL stuff later.
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]
