Hi,
On Wed, Oct 25, 2000 at 01:59:16AM +0200, Andreas Gruenbacher wrote:
>
> > 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.
Not true. AFS and NFSv4 work in terms of Kerberos. With AFS, they
currently generate temporary group IDs ("PAG"s, or Process
Authentication Groups) to track rights inheritance over fork, but the
ACLs are still done in terms of Kerberos principals. NFSv4 is also
Kerberos-authenticated, and has the kernel passing kerberos tickets
directly to a user-space GSS daemon.
The need for a typed interface for ACLs *already exists*, and if the
Samba people get their way it will only get worse.
> 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.
Sure --- for most permissions things, you can use PAGs, but for
setting ACLs you can't rely on them. PAGs give you the mapping you
need for permissions checking, but not for setting the ACLs in the
first place.
> 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.
Arrgh. You're forcing one API into another despite them being totally
different things on some filesystems. By forcing the interpretation
of the "system" namespace, you would obstruct other existing
filesystems which use that namespace differently. By forcing the ACL
to be flattened, you prevent proper running on top of filesystems
where you have only limited access to the full ACE list --- say
networked filesystems, where you may have the rights to set ACEs for
people in a certain group but not others.
> 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.
What about a separate VFS inode operations struct for AFS ACLs? Or
NCPFS ones? Or SMBFS ones? We could also make multiple different
operations entry points for XFS vs ext2 vs JFS vs NTFS EA semantics.
Or we could simply make the initial interface flexible enough for them
all.
> 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.
That is not always true on other filesystems. Either the API
recognises that, or it will simply not work for all filesystems.
> I would really appreciate if we could try to focus on EAs for a while, and
> address the ACL stuff later.
That's fine if you believe that just becasue they are completely
different, they need different syscalls. I don't, because the
division between "ACL" and "named extended attribute" is just one
example of the division between different types of attribute in
general.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
