[RFC][PATCH] extended attributes

[RFC][PATCH] extended attributes

[Nathan Scott]

hi folks,

I've been discussing a filesystem extended attributes API with Andreas
Gruenbacher (maintainer of the ext2/ext3 extended attributes patch[1])
which is suitable for other Linux filesystems as well, in an effort to
remove the differences between our current implementations and to help
out the people building services layered above this (especially Samba).
In doing so we have reviewed the earlier discussion[2,3] on this topic,
and have attempted to produce a new interface which I believe satisfies
many of the issues and ideas put forward there, while at the same time
ensuring that the interface is simple, and remains true to the design
of extended attributes being name:value pairs.

A manual page describing the system call interface can be found here[4].
We're very interested in feedback on this.  In partiular, Linus - would
you consider the patch below, which reserves system call numbers for
this interface?  That would be a big help to our collaborative effort.

We have written most of the code for XFS, and Andreas is working away on
the ext2/ext3 version.  Switching to a new syscall interface is going to
cause several compatibility issues for our existing users, of course, so
is not something we want to rush into before soliciting feedback and
(hopefully) getting some system call numbers reserved - otherwise we may
find ourselves needing to do a similar transition again later.

As a test case for the interface, we will now be able to use the same
POSIX ACL userspace[1,5] between XFS and ext2 without any on-disk format
changes in XFS - this was an important interface design goal for us XFS
folk, where our format is fixed in stone as it is also used by IRIX.

We have also begun discussions with some of the LSM developers, with the
goal of implementing POSIX capabilities and POSIX MAC (mandatory access
control) security extensions in Linux also,  Here we again expect to be
able to provide a filesystem independent view of these attributes, while
still preserving the on-disk XFS format for these attributes using the
simple namespace abstraction mechanism this new interface provides.

I've included some pointers[6,7,8,9,10] to other projects, developers,
discussions, etc. which I've come across who are in some way or another
interested in an extended attributes implementation in the base kernel
- just as examples of how various people are using (or planning to use)
the current ext2/ext3 and XFS interfaces on Linux.

cheers.

-- 
Nathan


[1] Extended attributes for ext2/ext3 and POSIX ACLs
    http://acl.bestbits.at/
[2] fs-devel extended attributes discussion
    http://marc.theaimsgroup.com/?l=linux-fsdevel&m=97222475218787&w=2
[3] Andrew Gildfind's interface comparison whitepaper
    http://acl.bestbits.at/pre/gildfind-acls.pdf
[4] New extattr(2) system call man pages
    http://acl.bestbits.at/man/extattr.2.html
    http://acl.bestbits.at/man/extattr.5.html
    http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/attr2/man/man2/extattr.2
[5] Common POSIX ACL implementation for Linux
    http://acl.bestbits.at/pipermail/acl-devel/2001-February/000495.html
    http://www.samba.org/samba/whatsnew/samba-2.2.0.html
[6] Andrew Morgan's Filesystem Capability patches
    http://www.kernel.org/pub/linux/libs/security/linux-privs/README
[7] LSM - Linux Security Module project
    http://www.linuxsecurity.com/articles/forums_article-2854.html
    http://mail.wirex.com/pipermail/linux-security-module/2001-October/002310.html
[8] DMAPI/XDSM specification - implemented in XFS via extended attributes
    http://www.opengroup.org/onlinepubs/9657099/
    http://oss.sgi.com/projects/xfs/dmapi.html
[9] SnapFS snapshot filesystem
    http://lwn.net/2001/0308/a/snapfs.php3
[10] Will Dyson's resurrection of BeFS for Linux 2.4
    http://cs.earlham.edu/~will/software/linux/kernel/BeFS.html
    http://marc.theaimsgroup.com/?l=linux-fsdevel&m=100431033704112&w=2


diff -Naur 2.4.14-pristine/arch/i386/kernel/entry.S 2.4.14-reserved/arch/i386/kernel/entry.S
--- 2.4.14-pristine/arch/i386/kernel/entry.S	Sat Nov  3 12:18:49 2001
+++ 2.4.14-reserved/arch/i386/kernel/entry.S	Wed Nov  7 10:02:59 2001
@@ -622,6 +622,9 @@
 	.long SYMBOL_NAME(sys_ni_syscall)	/* Reserved for Security */
 	.long SYMBOL_NAME(sys_gettid)
 	.long SYMBOL_NAME(sys_readahead)	/* 225 */
+	.long SYMBOL_NAME(sys_ni_syscall)	/* reserved for extattr  */
+	.long SYMBOL_NAME(sys_ni_syscall)	/* reserved for lextattr */
+	.long SYMBOL_NAME(sys_ni_syscall)	/* reserved for fextattr */
 
 	.rept NR_syscalls-(.-sys_call_table)/4
 		.long SYMBOL_NAME(sys_ni_syscall)
diff -Naur 2.4.14-pristine/include/asm-i386/unistd.h 2.4.14-reserved/include/asm-i386/unistd.h
--- 2.4.14-pristine/include/asm-i386/unistd.h	Thu Oct 18 03:03:03 2001
+++ 2.4.14-reserved/include/asm-i386/unistd.h	Wed Nov  7 10:02:59 2001
@@ -230,6 +230,9 @@
 #define __NR_security		223	/* syscall for security modules */
 #define __NR_gettid		224
 #define __NR_readahead		225
+#define __NR_extattr		226	/* syscall for extended attributes */
+#define __NR_lextattr		227	/* syscall for extended attributes */
+#define __NR_fextattr		228	/* syscall for extended attributes */
 
 /* user-visible error numbers are in the range -1 - -124: see <asm-i386/errno.h> */
 

Re: [RFC][PATCH] extended attributes

[Nathan Scott]

Quick follow up - I had to botch _one_ of the CC'd lists I guess...
"linux-xfs@oss.sgi.comc" -> "linux-xfs@oss.sgi.com".  *sigh*

cheers.

On Wed, Nov 07, 2001 at 11:12:24AM +1100, Nathan Scott wrote:
> hi folks,
> 
> I've been discussing a filesystem extended attributes API with Andreas
> Gruenbacher (maintainer of the ext2/ext3 extended attributes patch[1])
> which is suitable for other Linux filesystems as well, in an effort to
> remove the differences between our current implementations and to help
> out the people building services layered above this (especially Samba).
> In doing so we have reviewed the earlier discussion[2,3] on this topic,
> and have attempted to produce a new interface which I believe satisfies
> many of the issues and ideas put forward there, while at the same time
> ensuring that the interface is simple, and remains true to the design
> of extended attributes being name:value pairs.
> 
> A manual page describing the system call interface can be found here[4].
> We're very interested in feedback on this.  In partiular, Linus - would
> you consider the patch below, which reserves system call numbers for
> this interface?  That would be a big help to our collaborative effort.
> 
> We have written most of the code for XFS, and Andreas is working away on
> the ext2/ext3 version.  Switching to a new syscall interface is going to
> cause several compatibility issues for our existing users, of course, so
> is not something we want to rush into before soliciting feedback and
> (hopefully) getting some system call numbers reserved - otherwise we may
> find ourselves needing to do a similar transition again later.
> 
> As a test case for the interface, we will now be able to use the same
> POSIX ACL userspace[1,5] between XFS and ext2 without any on-disk format
> changes in XFS - this was an important interface design goal for us XFS
> folk, where our format is fixed in stone as it is also used by IRIX.
> 
> We have also begun discussions with some of the LSM developers, with the
> goal of implementing POSIX capabilities and POSIX MAC (mandatory access
> control) security extensions in Linux also,  Here we again expect to be
> able to provide a filesystem independent view of these attributes, while
> still preserving the on-disk XFS format for these attributes using the
> simple namespace abstraction mechanism this new interface provides.
> 
> I've included some pointers[6,7,8,9,10] to other projects, developers,
> discussions, etc. which I've come across who are in some way or another
> interested in an extended attributes implementation in the base kernel
> - just as examples of how various people are using (or planning to use)
> the current ext2/ext3 and XFS interfaces on Linux.
> 
> cheers.
> 
> -- 
> Nathan
> 
> 
> [1] Extended attributes for ext2/ext3 and POSIX ACLs
>     http://acl.bestbits.at/
> [2] fs-devel extended attributes discussion
>     http://marc.theaimsgroup.com/?l=linux-fsdevel&m=97222475218787&w=2
> [3] Andrew Gildfind's interface comparison whitepaper
>     http://acl.bestbits.at/pre/gildfind-acls.pdf
> [4] New extattr(2) system call man pages
>     http://acl.bestbits.at/man/extattr.2.html
>     http://acl.bestbits.at/man/extattr.5.html
>     http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/attr2/man/man2/extattr.2
> [5] Common POSIX ACL implementation for Linux
>     http://acl.bestbits.at/pipermail/acl-devel/2001-February/000495.html
>     http://www.samba.org/samba/whatsnew/samba-2.2.0.html
> [6] Andrew Morgan's Filesystem Capability patches
>     http://www.kernel.org/pub/linux/libs/security/linux-privs/README
> [7] LSM - Linux Security Module project
>     http://www.linuxsecurity.com/articles/forums_article-2854.html
>     http://mail.wirex.com/pipermail/linux-security-module/2001-October/002310.html
> [8] DMAPI/XDSM specification - implemented in XFS via extended attributes
>     http://www.opengroup.org/onlinepubs/9657099/
>     http://oss.sgi.com/projects/xfs/dmapi.html
> [9] SnapFS snapshot filesystem
>     http://lwn.net/2001/0308/a/snapfs.php3
> [10] Will Dyson's resurrection of BeFS for Linux 2.4
>     http://cs.earlham.edu/~will/software/linux/kernel/BeFS.html
>     http://marc.theaimsgroup.com/?l=linux-fsdevel&m=100431033704112&w=2
> 
> 
> diff -Naur 2.4.14-pristine/arch/i386/kernel/entry.S 2.4.14-reserved/arch/i386/kernel/entry.S
> --- 2.4.14-pristine/arch/i386/kernel/entry.S	Sat Nov  3 12:18:49 2001
> +++ 2.4.14-reserved/arch/i386/kernel/entry.S	Wed Nov  7 10:02:59 2001
> @@ -622,6 +622,9 @@
>  	.long SYMBOL_NAME(sys_ni_syscall)	/* Reserved for Security */
>  	.long SYMBOL_NAME(sys_gettid)
>  	.long SYMBOL_NAME(sys_readahead)	/* 225 */
> +	.long SYMBOL_NAME(sys_ni_syscall)	/* reserved for extattr  */
> +	.long SYMBOL_NAME(sys_ni_syscall)	/* reserved for lextattr */
> +	.long SYMBOL_NAME(sys_ni_syscall)	/* reserved for fextattr */
>  
>  	.rept NR_syscalls-(.-sys_call_table)/4
>  		.long SYMBOL_NAME(sys_ni_syscall)
> diff -Naur 2.4.14-pristine/include/asm-i386/unistd.h 2.4.14-reserved/include/asm-i386/unistd.h
> --- 2.4.14-pristine/include/asm-i386/unistd.h	Thu Oct 18 03:03:03 2001
> +++ 2.4.14-reserved/include/asm-i386/unistd.h	Wed Nov  7 10:02:59 2001
> @@ -230,6 +230,9 @@
>  #define __NR_security		223	/* syscall for security modules */
>  #define __NR_gettid		224
>  #define __NR_readahead		225
> +#define __NR_extattr		226	/* syscall for extended attributes */
> +#define __NR_lextattr		227	/* syscall for extended attributes */
> +#define __NR_fextattr		228	/* syscall for extended attributes */
>  
>  /* user-visible error numbers are in the range -1 - -124: see <asm-i386/errno.h> */
>  
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Nathan

Re: [RFC][PATCH] extended attributes

[Andi Kleen]

On Wed, Nov 07, 2001 at 11:12:24AM +1100, Nathan Scott wrote:
> A manual page describing the system call interface can be found here[4].
> We're very interested in feedback on this.  In partiular, Linus - would

The cursor support looks quite complicated. It doesn't even forbid 
storing the contents of the cursor buffer somewhere and has all
the standard problems with stateless cursors requiring nasty hacks
with dynamic data structures with parallel modification.
Stateless cursors are just nasty!

I think it would be better to have a statefull readdir instead.
The kernel supports it via the ->private_data field of struct file
(not through fork,but that looks like a generic vfs bug) 

EA_FIRST_ENTRY to reset the fd the first entry, EA_READ_ENTRY to 
read the next one.

It would not be inherently thread safe, but also not be worse
in this regard than standard readdir (requiring user locks)

It would also be possible to do a threadsafe interface although it would be 
a bit uglier: EA_GET_LISTSIZE to get the 
size of the buffer required, EA_GET_FULL_LIST to fetch a full
buffer with the names of all EAs, EAGAIN on race.

I think doing it in one of these ways would be far easier for the
user and easier for future kernel implementations.

-Andi

Re: [RFC][PATCH] extended attributes

[Alexander Viro]

On Wed, 7 Nov 2001, Andi Kleen wrote:

> I think it would be better to have a statefull readdir instead.
> The kernel supports it via the ->private_data field of struct file
> (not through fork,but that looks like a generic vfs bug) 

???  fork() just copies references to struct file.

Re: [RFC][PATCH] extended attributes

[Nathan Scott]

hello again Andi,

On Wed, Nov 07, 2001 at 02:32:18AM +0100, Andi Kleen wrote:
> I think it would be better to have a statefull readdir instead.
> The kernel supports it via the ->private_data field of struct file
> (not through fork,but that looks like a generic vfs bug) 
> 
> EA_FIRST_ENTRY to reset the fd the first entry, EA_READ_ENTRY to 
> read the next one.

I'm not sure this would work for the extattr/lextattr variants where
we don't have an fd to hold the state.  Should the list operation
be restricted to the fextattr variant, perhaps?  I'm not sure about
all the implications of that, will have to see what everyone else
thinks I guess.

eg. the opening of the file before allowing a list operation could
have implications for XFSs DMAPI support (open might recall data from
tape), where the management tools need to be able to list these DMAPI
related attributes without affecting the backing storage, I believe -
I'll have to ask some DMAPI gurus about that one though.

Thanks for the input.

cheers.

-- 
Nathan

Re: [Acl-Devel] Re: [RFC][PATCH] extended attributes

[Stephen Tweedie]

Hi,

On Wed, Nov 07, 2001 at 02:19:56PM +1100, Nathan Scott wrote:
> On Wed, Nov 07, 2001 at 02:32:18AM +0100, Andi Kleen wrote:
> > EA_FIRST_ENTRY to reset the fd the first entry, EA_READ_ENTRY to 
> > read the next one.
> 
> I'm not sure this would work for the extattr/lextattr variants where
> we don't have an fd to hold the state.

> eg. the opening of the file before allowing a list operation could
> have implications for XFSs DMAPI support (open might recall data from
> tape),

There are other much more immediate obstacles: opening /dev/* is not
possible if the devices beneath the inodes don't exist.

O_OPENONLY (implying neither read nor write access) to get a stub file
handle for such inodes is possible, if a bit hackish.  There's a
problem in the kernel there --- kernel file descriptor operations on
"special" inodes such as named sockets/pipes or device nodes don't
pass file operations on to the underlying filesystem.  

As long as you're doing the ACL stuff via inode operations internally,
that's not a problem.  However, inode operations generally don't take
a file descriptor as an argument so you don't have access to the
cursor in that case.

The DMAPI and special inode problems go away if you don't demand a
file descriptor to the file.  (Having a file descriptor that
specifically belongs to the ACL stream is a different matter
entirely.)

--Stephen

Re: [RFC][PATCH] extended attributes

[Andi Kleen]

On Wed, Nov 07, 2001 at 02:19:56PM +1100, Nathan Scott wrote:
> I'm not sure this would work for the extattr/lextattr variants where
> we don't have an fd to hold the state.  Should the list operation

Right. I forgot that.

Then I guess it is better to use EA_LIST_SIZE / EA_GET_LIST (EAGAIN on race)

Whole point is to just avoid to have an stateless cursor. 

-Andi

Re: [RFC][PATCH] extended attributes

[Nathan Scott]

On Wed, Nov 07, 2001 at 02:32:18AM +0100, Andi Kleen wrote:
> On Wed, Nov 07, 2001 at 11:12:24AM +1100, Nathan Scott wrote:
> > A manual page describing the system call interface can be found here[4].
> > We're very interested in feedback on this.  In particular, Linus - would
> 
> The cursor support looks quite complicated.  ...
> Stateless cursors are just nasty!
> ...

hi folks,

We've removed the cursor operations, and gone back to Andreas'
original, simpler list approach.  Revised versions of the two
extattr man pages are in the XFS CVS repository, or use:
	http://acl.bestbits.at/man/extattr.2.html
	http://acl.bestbits.at/man/extattr.5.html

I notice that 2.4.15-pre3 doesn't have the patch below - Linus,
Alan, could you please apply it? - it will help us a great deal.
This would be useful to the ext2/ext3, InterMezzo/SnapFS, NTFS,
XFS, JFS and BeFS filesystem implementations for Linux, and to
any other filesystems planning to support extended attributes
in the future as well.

many thanks.

-- 
Nathan


diff -Naur 2.4.14-pristine/arch/i386/kernel/entry.S 2.4.14-reserved/arch/i386/kernel/entry.S
--- 2.4.14-pristine/arch/i386/kernel/entry.S	Sat Nov  3 12:18:49 2001
+++ 2.4.14-reserved/arch/i386/kernel/entry.S	Wed Nov  7 10:02:59 2001
@@ -622,6 +622,9 @@
 	.long SYMBOL_NAME(sys_ni_syscall)	/* Reserved for Security */
 	.long SYMBOL_NAME(sys_gettid)
 	.long SYMBOL_NAME(sys_readahead)	/* 225 */
+	.long SYMBOL_NAME(sys_ni_syscall)	/* reserved for extattr  */
+	.long SYMBOL_NAME(sys_ni_syscall)	/* reserved for lextattr */
+	.long SYMBOL_NAME(sys_ni_syscall)	/* reserved for fextattr */
 
 	.rept NR_syscalls-(.-sys_call_table)/4
 		.long SYMBOL_NAME(sys_ni_syscall)
diff -Naur 2.4.14-pristine/include/asm-i386/unistd.h 2.4.14-reserved/include/asm-i386/unistd.h
--- 2.4.14-pristine/include/asm-i386/unistd.h	Thu Oct 18 03:03:03 2001
+++ 2.4.14-reserved/include/asm-i386/unistd.h	Wed Nov  7 10:02:59 2001
@@ -230,6 +230,9 @@
 #define __NR_security		223	/* syscall for security modules */
 #define __NR_gettid		224
 #define __NR_readahead		225
+#define __NR_extattr		226	/* syscall for extended attributes */
+#define __NR_lextattr		227	/* syscall for extended attributes */
+#define __NR_fextattr		228	/* syscall for extended attributes */
 
 /* user-visible error numbers are in the range -1 - -124: see <asm-i386/errno.h> */
 

RE: [RFC][PATCH] extended attributes

[Luka Renko]

In http://acl.bestbits.at/man/extattr.5.html there is a statement:

   Device special files cannot be associated with extended user attributes 

What is the reason for this limitation? Why should there be a difference
between regular files/directories and special files (device files)?

I am also thinking in terms of HSM application (or DMAPI if you want). Where
do you want HSM attributes to be placed? I thought it should be in trusted,
because we might need access to them from user space. Other option is system
(that would require accessing them from kernel code) or user (might be
problematic, since regular user with write permission might remove them...
Actually, where are XFS guys storing DMAPI attributes today?

Regards,
Luka

> -----Original Message-----
> From: Nathan Scott [mailto:nathans@sgi.com] 
> Sent: Wednesday, November 07, 2001 01:12
> To: Linus Torvalds; Andreas Gruenbacher
> Cc: linux-kernel@vger.kernel.org; 
> linux-fsdevel@vger.kernel.org; acl-devel@bestbits.at; 
> linux-xfs@hermes.si
> Subject: [RFC][PATCH] extended attributes
> 
> 
> hi folks,
> 
> I've been discussing a filesystem extended attributes API 
> with Andreas Gruenbacher (maintainer of the ext2/ext3 
> extended attributes patch[1]) which is suitable for other 
> Linux filesystems as well, in an effort to remove the 
> differences between our current implementations and to help 
> out the people building services layered above this 
> (especially Samba). In doing so we have reviewed the earlier 
> discussion[2,3] on this topic, and have attempted to produce 
> a new interface which I believe satisfies many of the issues 
> and ideas put forward there, while at the same time ensuring 
> that the interface is simple, and remains true to the design 
> of extended attributes being name:value pairs.
> 
> A manual page describing the system call interface can be 
> found here[4]. We're very interested in feedback on this.  In 
> partiular, Linus - would you consider the patch below, which 
> reserves system call numbers for this interface?  That would 
> be a big help to our collaborative effort.
> 
> We have written most of the code for XFS, and Andreas is 
> working away on the ext2/ext3 version.  Switching to a new 
> syscall interface is going to cause several compatibility 
> issues for our existing users, of course, so is not something 
> we want to rush into before soliciting feedback and
> (hopefully) getting some system call numbers reserved - 
> otherwise we may find ourselves needing to do a similar 
> transition again later.
> 
> As a test case for the interface, we will now be able to use 
> the same POSIX ACL userspace[1,5] between XFS and ext2 
> without any on-disk format changes in XFS - this was an 
> important interface design goal for us XFS folk, where our 
> format is fixed in stone as it is also used by IRIX.
> 
> We have also begun discussions with some of the LSM 
> developers, with the goal of implementing POSIX capabilities 
> and POSIX MAC (mandatory access
> control) security extensions in Linux also,  Here we again 
> expect to be able to provide a filesystem independent view of 
> these attributes, while still preserving the on-disk XFS 
> format for these attributes using the simple namespace 
> abstraction mechanism this new interface provides.
> 
> I've included some pointers[6,7,8,9,10] to other projects, 
> developers, discussions, etc. which I've come across who are 
> in some way or another interested in an extended attributes 
> implementation in the base kernel
> - just as examples of how various people are using (or 
> planning to use) the current ext2/ext3 and XFS interfaces on Linux.
> 
> cheers.
> 
> -- 
> Nathan
> 
> 
> [1] Extended attributes for ext2/ext3 and POSIX ACLs
>     http://acl.bestbits.at/
> [2] fs-devel extended attributes discussion
>     http://marc.theaimsgroup.com/?l=linux-fsdevel&m=97222475218787&w=2
> [3] Andrew Gildfind's interface comparison whitepaper
>     http://acl.bestbits.at/pre/gildfind-acls.pdf
> [4] New extattr(2) system call man pages
>     http://acl.bestbits.at/man/extattr.2.html
>     http://acl.bestbits.at/man/extattr.5.html
>     
> http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/attr2/
man/man2/extattr.2
> [5] Common POSIX ACL implementation for Linux
>     
> http://acl.bestbits.at/pipermail/acl-devel/2001-February/000495.html
>     http://www.samba.org/samba/whatsnew/samba-2.2.0.html
> [6] Andrew Morgan's Filesystem Capability patches
>     http://www.kernel.org/pub/linux/libs/security/linux-privs/README
> [7] LSM - Linux Security Module project
>     http://www.linuxsecurity.com/articles/forums_article-2854.html
>     
> http://mail.wirex.com/pipermail/linux-security-module/2001-Oct
ober/002310.html
[8] DMAPI/XDSM specification - implemented in XFS via extended attributes
    http://www.opengroup.org/onlinepubs/9657099/
    http://oss.sgi.com/projects/xfs/dmapi.html
[9] SnapFS snapshot filesystem
    http://lwn.net/2001/0308/a/snapfs.php3
[10] Will Dyson's resurrection of BeFS for Linux 2.4
    http://cs.earlham.edu/~will/software/linux/kernel/BeFS.html
    http://marc.theaimsgroup.com/?l=linux-fsdevel&m=100431033704112&w=2


diff -Naur 2.4.14-pristine/arch/i386/kernel/entry.S
2.4.14-reserved/arch/i386/kernel/entry.S
--- 2.4.14-pristine/arch/i386/kernel/entry.S	Sat Nov  3 12:18:49 2001
+++ 2.4.14-reserved/arch/i386/kernel/entry.S	Wed Nov  7 10:02:59 2001
@@ -622,6 +622,9 @@
 	.long SYMBOL_NAME(sys_ni_syscall)	/* Reserved for Security */
 	.long SYMBOL_NAME(sys_gettid)
 	.long SYMBOL_NAME(sys_readahead)	/* 225 */
+	.long SYMBOL_NAME(sys_ni_syscall)	/* reserved for extattr  */
+	.long SYMBOL_NAME(sys_ni_syscall)	/* reserved for lextattr */
+	.long SYMBOL_NAME(sys_ni_syscall)	/* reserved for fextattr */
 
 	.rept NR_syscalls-(.-sys_call_table)/4
 		.long SYMBOL_NAME(sys_ni_syscall)
diff -Naur 2.4.14-pristine/include/asm-i386/unistd.h
2.4.14-reserved/include/asm-i386/unistd.h
--- 2.4.14-pristine/include/asm-i386/unistd.h	Thu Oct 18 03:03:03 2001
+++ 2.4.14-reserved/include/asm-i386/unistd.h	Wed Nov  7 10:02:59 2001
@@ -230,6 +230,9 @@
 #define __NR_security		223	/* syscall for security modules */
 #define __NR_gettid		224
 #define __NR_readahead		225
+#define __NR_extattr		226	/* syscall for extended attributes
*/
+#define __NR_lextattr		227	/* syscall for extended attributes
*/
+#define __NR_fextattr		228	/* syscall for extended attributes
*/
 
 /* user-visible error numbers are in the range -1 - -124: see
<asm-i386/errno.h> */
 
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html

RE: [RFC][PATCH] extended attributes

[Andreas Gruenbacher]

On Thu, 8 Nov 2001, Luka Renko wrote:

> In http://acl.bestbits.at/man/extattr.5.html there is a statement:
> 
>    Device special files cannot be associated with extended user attributes 
> 
> What is the reason for this limitation? Why should there be a difference
> between regular files/directories and special files (device files)?

This limitation has been introduced since allowing extended user
attributes for special files leads to an awkward semantic mess: Extended
user attributes are in a sense treaded like file contents (concerning
permissions, for example). Now the "contents" of a special file are a
device, really. The device isn't even located on the filesystem the
special file is on. And the device doesn't have extended attributes.

It is possible to have devices on read-only file systems, which are
readable and writeable. It would not be possible to have extended
attributes in that case.

> I am also thinking in terms of HSM application (or DMAPI if you want). Where
> do you want HSM attributes to be placed? I thought it should be in trusted,
> because we might need access to them from user space. Other option is system
> (that would require accessing them from kernel code) or user (might be
> problematic, since regular user with write permission might remove them...

I am not sure about this. Just note that XFS and current ext2/ext3 don't
yet have the owner and trusted namespaces.

--Andreas.

Re: [RFC][PATCH] extended attributes

[Dean Roehrich]

>From:  Luka Renko <luka.renko@hermes.si>
>I am also thinking in terms of HSM application (or DMAPI if you want). Where
>do you want HSM attributes to be placed? I thought it should be in trusted,
>because we might need access to them from user space. Other option is system
>(that would require accessing them from kernel code) or user (might be
>problematic, since regular user with write permission might remove them...
>Actually, where are XFS guys storing DMAPI attributes today?

On XFS the DMAPI event mask for that file is kept in a field in the
xfs_dinode_core_t structure--so it's in the inode.  On Irix, HSM's store state
info in an extended attribute in the "root" namespace on each file, but they
do it via the appropriate DMAPI calls (which jump to XFS's extended attribute
code) rather than via the extended attribute library.


Dean

[RFC][PATCH] extended attributes

[Tim R.]

Hi,
I'm glad to see you guys are working on a common acl api for ext2/3 and xfs.
I was just wondering if this api provided what would be needed for linux 
to support NTFS's acls.
Now bare in mind I know little about how NTFS's alc's are implimented or 
if they follow POSIX at
all. But I just thought it might be worth asking the ntfs maintainer if 
the proposed api would be
adaquit to support ntfs's acls on linux should they ever want to 
impliment this. Might save them
headaches someday.
Also will it supply the interface needed for other filesystems that have 
been ported that linux that
support acls? (i.e. will it work for them, could they use it in the 
future if/when they decide to
impliment that feature) I think JFS might support acls too.

Sorry to be a bother,
Tim

Re: [RFC][PATCH] extended attributes

[Nathan Scott]

hi Tim,

On Sat, Nov 10, 2001 at 04:08:50AM -0500, Tim R. wrote:
> I'm glad to see you guys are working on a common acl api for ext2/3 and xfs.
> I was just wondering if this api provided what would be needed for linux 
> to support NTFS's acls.
> Now bare in mind I know little about how NTFS's alc's are implimented or 
> if they follow POSIX at
> all. But I just thought it might be worth asking the ntfs maintainer if 
> the proposed api would be
> adaquit to support ntfs's acls on linux should they ever want to 
> impliment this. Might save them
> headaches someday.

The API doesn't favour any one form of ACL - it allows for any
implementation to be layered above it, provided the semantics
of those ACLs can be expressed using extended attributes, of
course.

> Also will it supply the interface needed for other filesystems that have 
> been ported that linux that
> support acls? (i.e. will it work for them, could they use it in the 
> future if/when they decide to
> impliment that feature) I think JFS might support acls too.

Yes, I believe so.  I see EA and ACL support is on the JFS todo
list - I was contacted by some folk at IBM who let me know this,
so there is certainly some interest there.

cheers.

-- 
Nathan

Re: [RFC][PATCH] extended attributes

[Anton Altaparmakov]

At 09:08 10/11/2001, Tim R. wrote:
>I'm glad to see you guys are working on a common acl api for ext2/3 and xfs.
>I was just wondering if this api provided what would be needed for linux 
>to support NTFS's acls.
>Now bare in mind I know little about how NTFS's alc's are implimented or 
>if they follow POSIX at
>all. But I just thought it might be worth asking the ntfs maintainer if 
>the proposed api would be
>adaquit to support ntfs's acls on linux should they ever want to impliment 
>this. Might save them
>headaches someday.

Comments/problems for NTFS with proposed EA/ACL API:

I think the API is good for extended attributes, no doubt. If we ever get 
round to implementing EAs in NTFS then I would be happy to use the API. It 
fully satisfies the needs of the NTFS EAs. The only addition I would put 
into the API is that the names of the extended attributes have to be able 
to have different name spaces themselves. For example I am fairly sure that 
the name of an EA in NTFS cannot contain just any character and it 
certainly cannot have a name of any length... This is something that needs 
to be considered. At least there must be a defined error return values of 
"EILSEQ" (bad name namespace) and "ENAMETOOLONG" (self evident).

But for ACLs I am not so positive:

I guess the real problem is that NTFS security doesn't map very well onto 
Unix/Linux type of security model because the NTFS model has way more features.

If you are asking the question whether NTFS can work with the proposed API 
then yes, it can support all its features, but not the other way round...

Particular problems:

- The proposed API puts ACLs inside extended attributes (EAs). On NTFS ACLs 
have nothing to do with extended attributes. They are two entirely 
different things. I suppose they could be merged into one API and the NTFS 
driver would have to parse and decide whether it is supposed to be 
operating on ACLs or EAs. But that will be a pain, especially as there may 
be ways of abusing the system, depending on how exactly it is implemented.

- The ACLs in NTFS are _way_ more complex than the suggested ones. So 
mapping from one to the other is possible only when creating new files. 
When reading/writing existing ACLs a lot of information would be lost.

Further each inode has a "user" owner and a group "owner" plus two types of 
ACLs: system one (SACL) and discretionary "normal" one (DACL).

These four thigns are stored within a self relative security descriptor. 
And some of them are optional or can be inherited from parent inode or can 
be defaulted. - This actually breaks the current API which says that files 
cannot inherit/default file ACLs. In NTFS they can.

The actual permissions in NTFS are not just RWX but they are a lot more 
granular (a 32 bitfield, see below URL for a list of all defined values) 
and some of them even determine the access rights to extended attributes, 
which needless to say causes a problem if ACLs are treated as EAs...

- NTFS doesn't store uids but Security Identifiers (SID ones not 
Security_ID ones, both are separate things on NTFS. Are you confused yet? I 
am...) so mapping would need to exist between NTFS SID and Linux UIDs. 
Samba needs to do this (and does it already AFAIK), too, but that is more a 
problem of NTFS and not a Linux ACL API.

All NTFS security stuff can be seen at the following URL - just search for 
IDENTIFIER_AUTHORITY and read from there on... all security related 
structures are defined there and there are quite a few comments.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/linux-ntfs/ntfs-driver-tng/linux/include/linux/ntfs_layout.h?rev=1.11&content-type=text/vnd.viewcvs-markup

You can also read the NTFS documentation on SF but note that this is not as 
complete as the header file above but it might be easier to understand. The 
url with the description of the security descriptor is:

http://linux-ntfs.sourceforge.net/ntfs/attributes/security_descriptor.html

Best regards,

         Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: [RFC][PATCH] extended attributes

[Nathan Scott]

hi Anton,

On Mon, Nov 12, 2001 at 01:57:28AM +0000, Anton Altaparmakov wrote:
> At 09:08 10/11/2001, Tim R. wrote:
> >I'm glad to see you guys are working on a common acl api for ext2/3 and xfs.
> >I was just wondering if this api provided what would be needed for linux 
> >to support NTFS's acls.
> 
> Comments/problems for NTFS with proposed EA/ACL API:
> 
> I think the API is good for extended attributes, no doubt. If we ever get 
> round to implementing EAs in NTFS then I would be happy to use the API. It 
> fully satisfies the needs of the NTFS EAs.

That's great to hear!  Thanks.

> The only addition I would put 
> into the API is that the names of the extended attributes have to be able 
> to have different name spaces themselves. For example I am fairly sure that 
> the name of an EA in NTFS cannot contain just any character and it 
> certainly cannot have a name of any length... This is something that needs 
> to be considered.

Agreed.  I think the determination of what is a valid attribute
name and what are the max name lengths, etc. will have to be
done within the filesystem, as we have already come across these
sorts of differences when reconciling the XFS EAs (from IRIX)
with Andreas' ext2/3 ones.  

I'll put out an initial attempt at some VFS code to sit behind
this system call soon too.

> I guess the real problem is that NTFS security doesn't map very well onto 
> Unix/Linux type of security model because the NTFS model has way more features.
> 
> If you are asking the question whether NTFS can work with the proposed API 
> then yes, it can support all its features, but not the other way round...
> 
> Particular problems:
> 
> - The proposed API puts ACLs inside extended attributes (EAs).

By "proposed API" I assume you are talking about Andreas' POSIX ACL
implementation?  (i.e. not this API for extended attributes, which
we have described here, as this is not specific to any form of ACLs).

I don't think anyone has ever proposed that the NTFS ACLs need to
use the same userspace tools as Andreas' POSIX ACL implementation -
I'm not sure that makes any sense at all.

> On NTFS ACLs have nothing to do with extended attributes.

Yup and right there this extended attribute system call API becomes
inappropriate for NTFS ACLs, right?  It is not that its a limitation
of this API, it is that NTFS does not use EAs to store ACLs.  Using
a crowbar to try to force that association is almost certainly not
a good idea.

> They are two entirely different things.

*nod*

> I suppose they could be merged into one API and the NTFS 
> driver would have to parse and decide whether it is supposed to be 
> operating on ACLs or EAs. But that will be a pain, especially as there may 
> be ways of abusing the system, depending on how exactly it is implemented.

If you do implement NT ACLs in NTFS, then it sounds like you would
be better off using a different API to this extended attribute one.
Andreas has several thoughts on this - he knows plenty more about
ACLs than I, having researched this area alot and having completely
implemented POSIX ACLs for ext2/3 from scratch.  I have read mail
from him saying that given the different semantics of the numerous
forms of ACL, that a single ACL API is inappropriate/impossible.

It is convenient for us in XFS and ext2/3 to be able to use extended
attributes to implement POSIX ACLs - because these filesystems all
really do implement POSIX ACLs using extended attributes.  Of course,
this doesn't necessarily mean that it will be convenient for other
filesystems that don't implement their particular flavour of ACLs as
extended attributes.

Thanks for the feedback, Anton - much appreciated.

cheers.

-- 
Nathan