Re: [RFC][PATCH] Generic fallback for security xattrs
* Christoph Hellwig ([EMAIL PROTECTED]) wrote:
> On Fri, Aug 19, 2005 at 01:57:56PM -0400, Stephen Smalley wrote:
> > Note that this
> > approach may be controversial [1]; it has been suggested that we
> > should instead be modifying all filesystem types to support security
> > (and other) xattrs natively, but this seems questionable for legacy
> > filesystems like vfat and pseudo filesystems like proc, especially
> > when the resulting code will end up simply calling the security
> > framework to access the incore security label as with the current
> > devpts and tmpfs handlers.
Agreed, I think the counter points that were made were not reasonable.
> > The patch restructures the code flow slightly to reduce duplication
> > between the normal path and the fallback path, but this should only have
> > one user-visible side effect - a program may get -EACCES rather than
> > -EOPNOTSUPP if policy denied access but the filesystem didn't support
> > the operation anyway. Note that the post_setxattr hook call is not
> > needed in the fallback case, as the inode_setsecurity hook call handles
> > the incore inode security state update directly. In contrast, we do
> > call fsnotify in both cases.
> >
> > Let me know what you think. Please do NOT apply yet.
>
> Very nice, and gets rid of lots of crap. Now that we started parsing
> the attribute name in generic code we should deprecate the old
> ->{get,set,list,remove}xattr inode operations and make the helpers
> James added a while ago mandatory for the future.
I agree it's a nice cleanup. The only thing I didn't care for was parsing
name in generic code (since it was special cased as the only name), but
you make a great point. There are toplevel generic names which each fs
has to parse anyway.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] Generic fallback for security xattrs
Christoph Hellwig wrote:
> Very nice, and gets rid of lots of crap. Now that we started parsing
> the attribute name in generic code we should deprecate the old
> ->{get,set,list,remove}xattr inode operations and make the helpers
> James added a while ago mandatory for the future.
I'd be fine with making the generic xattr routines the default with a
few exceptions:
1) Pass the entire name of the xattr (including prefix) to the
underlying filesystem. ReiserFS needs the entire name, including the
prefix, to look up an xattr. Reconstructing the name again, when it was
available in the caller, is wasteful. Once the determination of the
prefix is made, the filesystem code can just skip the prefix length
anyway if it doesn't need it.
2) Keep i_op->listxattr. For xattrs like system.posix_acl_access, sure,
it makes sense. But when selinux or user xattrs are introduced, the name
and number of such xattrs will be unknown to a generic routine.
I have a series of patches for reiserfs xattrs that I'm still working
the kinks out of, mainly performance-wise. With the patch set applied,
reiserfs_{set,get,remove}xattr look identical to the generic versions,
except that find_xattr_handler_prefix doesn't modify the name.
-Jeff
--
Jeff Mahoney
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH] Generic fallback for security xattrs
This is a request for comments (only) on the patch below that modifies
the VFS setxattr, getxattr, and listxattr code to fall back to the
security module for security xattrs if the filesystem does not support
xattrs natively. This allows security modules to export the incore
inode security label information to userspace even if the filesystem
does not provide xattr storage, and eliminates the need to
individually patch various pseudo filesystem types to provide such
access (note that this patch removes the existing xattr code from
devpts and tmpfs as it is then no longer needed). Note that this
approach may be controversial [1]; it has been suggested that we
should instead be modifying all filesystem types to support security
(and other) xattrs natively, but this seems questionable for legacy
filesystems like vfat and pseudo filesystems like proc, especially
when the resulting code will end up simply calling the security
framework to access the incore security label as with the current
devpts and tmpfs handlers.
The patch restructures the code flow slightly to reduce duplication
between the normal path and the fallback path, but this should only have
one user-visible side effect - a program may get -EACCES rather than
-EOPNOTSUPP if policy denied access but the filesystem didn't support
the operation anyway. Note that the post_setxattr hook call is not
needed in the fallback case, as the inode_setsecurity hook call handles
the incore inode security state update directly. In contrast, we do
call fsnotify in both cases.
Let me know what you think. Please do NOT apply yet.
A prior discussion thread on this patch on the linux-security-module
list is available at
[1] http://marc.theaimsgroup.com/?t=11214414723&r=1&w=2
---
fs/Kconfig | 43 --
fs/devpts/Makefile |1
fs/devpts/inode.c | 21 ---
fs/devpts/xattr_security.c | 47
fs/xattr.c | 80 +-
mm/shmem.c | 85 -
6 files changed, 49 insertions(+), 228 deletions(-)
diff -X /home/sds/dontdiff -Nrup linux-2.6.13-rc6-mm1/fs/devpts/inode.c
linux-2.6.13-rc6-mm1-xattr/fs/devpts/inode.c
--- linux-2.6.13-rc6-mm1/fs/devpts/inode.c 2005-06-17 15:48:29.0
-0400
+++ linux-2.6.13-rc6-mm1-xattr/fs/devpts/inode.c2005-08-19
13:02:58.0 -0400
@@ -18,28 +18,9 @@
#include
#include
#include
-#include
#define DEVPTS_SUPER_MAGIC 0x1cd1
-extern struct xattr_handler devpts_xattr_security_handler;
-
-static struct xattr_handler *devpts_xattr_handlers[] = {
-#ifdef CONFIG_DEVPTS_FS_SECURITY
- &devpts_xattr_security_handler,
-#endif
- NULL
-};
-
-static struct inode_operations devpts_file_inode_operations = {
-#ifdef CONFIG_DEVPTS_FS_XATTR
- .setxattr = generic_setxattr,
- .getxattr = generic_getxattr,
- .listxattr = generic_listxattr,
- .removexattr= generic_removexattr,
-#endif
-};
-
static struct vfsmount *devpts_mnt;
static struct dentry *devpts_root;
@@ -102,7 +83,6 @@ devpts_fill_super(struct super_block *s,
s->s_blocksize_bits = 10;
s->s_magic = DEVPTS_SUPER_MAGIC;
s->s_op = &devpts_sops;
- s->s_xattr = devpts_xattr_handlers;
s->s_time_gran = 1;
inode = new_inode(s);
@@ -175,7 +155,6 @@ int devpts_pty_new(struct tty_struct *tt
inode->i_gid = config.setgid ? config.gid : current->fsgid;
inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME;
init_special_inode(inode, S_IFCHR|config.mode, device);
- inode->i_op = &devpts_file_inode_operations;
inode->u.generic_ip = tty;
dentry = get_node(number);
diff -X /home/sds/dontdiff -Nrup linux-2.6.13-rc6-mm1/fs/devpts/Makefile
linux-2.6.13-rc6-mm1-xattr/fs/devpts/Makefile
--- linux-2.6.13-rc6-mm1/fs/devpts/Makefile 2005-06-17 15:48:29.0
-0400
+++ linux-2.6.13-rc6-mm1-xattr/fs/devpts/Makefile 2005-08-19
13:03:07.0 -0400
@@ -5,4 +5,3 @@
obj-$(CONFIG_UNIX98_PTYS) += devpts.o
devpts-$(CONFIG_UNIX98_PTYS) := inode.o
-devpts-$(CONFIG_DEVPTS_FS_SECURITY)+= xattr_security.o
diff -X /home/sds/dontdiff -Nrup
linux-2.6.13-rc6-mm1/fs/devpts/xattr_security.c
linux-2.6.13-rc6-mm1-xattr/fs/devpts/xattr_security.c
--- linux-2.6.13-rc6-mm1/fs/devpts/xattr_security.c 2005-06-17
15:48:29.0 -0400
+++ linux-2.6.13-rc6-mm1-xattr/fs/devpts/xattr_security.c 1969-12-31
19:00:00.0 -0500
@@ -1,47 +0,0 @@
-/*
- * Security xattr support for devpts.
- *
- * Author: Stephen Smalley <[EMAIL PROTECTED]>
- * Copyright (c) 2004 Red Hat, Inc., James Morris <[EMAIL PROTECTED]>
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the Free
- * Software Foundation; ei
Re: [RFC][PATCH] Generic fallback for security xattrs
On Fri, Aug 19, 2005 at 01:57:56PM -0400, Stephen Smalley wrote:
> This is a request for comments (only) on the patch below that modifies
> the VFS setxattr, getxattr, and listxattr code to fall back to the
> security module for security xattrs if the filesystem does not support
> xattrs natively. This allows security modules to export the incore
> inode security label information to userspace even if the filesystem
> does not provide xattr storage, and eliminates the need to
> individually patch various pseudo filesystem types to provide such
> access (note that this patch removes the existing xattr code from
> devpts and tmpfs as it is then no longer needed). Note that this
> approach may be controversial [1]; it has been suggested that we
> should instead be modifying all filesystem types to support security
> (and other) xattrs natively, but this seems questionable for legacy
> filesystems like vfat and pseudo filesystems like proc, especially
> when the resulting code will end up simply calling the security
> framework to access the incore security label as with the current
> devpts and tmpfs handlers.
>
> The patch restructures the code flow slightly to reduce duplication
> between the normal path and the fallback path, but this should only have
> one user-visible side effect - a program may get -EACCES rather than
> -EOPNOTSUPP if policy denied access but the filesystem didn't support
> the operation anyway. Note that the post_setxattr hook call is not
> needed in the fallback case, as the inode_setsecurity hook call handles
> the incore inode security state update directly. In contrast, we do
> call fsnotify in both cases.
>
> Let me know what you think. Please do NOT apply yet.
Very nice, and gets rid of lots of crap. Now that we started parsing
the attribute name in generic code we should deprecate the old
->{get,set,list,remove}xattr inode operations and make the helpers
James added a while ago mandatory for the future.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
