* re: User-manageable sub-ids proposals
@ 2001-12-13 16:02 Jacques Gelinas
0 siblings, 0 replies; 8+ messages in thread
From: Jacques Gelinas @ 2001-12-13 16:02 UTC (permalink / raw)
To: linux-kernel
On Thu, 13 Dec 2001 11:36:16 -0500, Romano Giannetti wrote
> Good morning to everyone.
>
> I was thinking about the idea of sub-ids to enable users to run "untrusted"
> binary or "dangerous" one without risk for their files/privacy.
I have another solution, which is almost completed. I am combining
two project. One is the vserver project (see the url in my signature) and the
other is the AclFS component of the virtualfs project
(http://www.solucorp.qc.ca/virtualfs).
Using the chcontext utility from the vserver project, you can isolate a process
from the rest of the system, including the other user processes
For example, as a normal user, you can do
xterm &
/usr/sbin/chcontext /bin/sh
ps ax
killall xterm
and you only see your new shell, the ps command and init. The killall fails
finding no xterm to kill.
Another part of the vserver project is the capability ceiling, which is a way to
turn off some capabilities for a process and its children, even setuid child.
I was thinking about introducing a new capability CAP_OPEN. This capability
would prevent any open system call from succeeding. Wow. Now that's secure :-)
The acslfs daemon works using a unix domain socket. Using a preload object
the client does various system call request to aclfsd, including open, socket
and so on. If aclfsd grant the access, it opens the file and pass back the
file handle using the socket. So the client does not need to open the file
itself.
So the CAP_OPEN is there to force the client to use aclfsd. Even if using aclfsd
is transparent to normal clients, some client might do a direct call to the OS.
All those calls would fail.
Not also that aclfsd does not need any privilege. A normal user may start
it with its own configurations (access privileges).
Ultimatly, one goal of this would be to run your favorite browser in a security
box and allow fine grain access to your own file. Then one could do the so
cool thing windows user do all the time: They visit a site, select a plugin
and run it. Unlike windows, you would not get all the virus though :-)
Anyway, the vserver and virtual projects are used for different purpose today
but could be combined to achieve this kind of result.
---------------------------------------------------------
Jacques Gelinas <jack@solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!
http://www.solucorp.qc.ca/miscprj/s_context.hc
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH] Revised extended attributes interface
@ 2001-12-05 3:32 Nathan Scott
2001-12-07 20:20 ` Stephen C. Tweedie
0 siblings, 1 reply; 8+ messages in thread
From: Nathan Scott @ 2001-12-05 3:32 UTC (permalink / raw)
To: Linus Torvalds, Alexander Viro, Andi Kleen, Andreas Gruenbacher
Cc: linux-kernel, linux-fsdevel, linux-xfs
> On December 3, 2001 01:54 am, Nathan Scott wrote:
> > ...BTW, we have reworked the interfaces once more and will
> > send out the latest revision in the next couple of days -
hi folks,
Here is the revised interface. I believe it takes into account
the issues raised so far - further suggestions are also welcome,
of course.
Man pages for the system calls are available from the XFS CVS tree
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/attr2/man/
[Andreas, could you host html-ised versions at bestbits.at again?]
The interesting pages are getxattr(2), setxattr(2), listxattr(2),
removexattr(2) and attr(5), though there are several user tools
based on this interface too and a version of Andreas' POSIX ACL
tools which makes use of this interface now exists (these also have
man pages and are all available from the XFS CVS tree).
Two patches follow - the first marks syscall numbers as reserved,
the second is the proposed VFS interface. These are patches based
on the 2.5.0 tree, but should apply cleanly to any 2.5.1-preX and
2.4.16/17-preX tree. Linus - if possible, we'd really like to get
system call numbers reserved for these, or know of any aspects you
would like changed in order to make this acceptable for 2.5.
many thanks.
--
Nathan
[1st patch]
diff -Naur 2.5.0-pristine/arch/i386/kernel/entry.S 2.5.0-reserved/arch/i386/kernel/entry.S
--- 2.5.0-pristine/arch/i386/kernel/entry.S Sat Nov 3 12:18:49 2001
+++ 2.5.0-reserved/arch/i386/kernel/entry.S Tue Dec 4 11:57:32 2001
@@ -622,6 +622,18 @@
.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 setxattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for lsetxattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for fsetxattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for getxattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* 230 reserved for lgetxattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for fgetxattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for listxattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for llistxattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for flistxattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* 235 reserved for removexattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for lremovexattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for fremovexattr */
.rept NR_syscalls-(.-sys_call_table)/4
.long SYMBOL_NAME(sys_ni_syscall)
diff -Naur 2.5.0-pristine/include/asm-i386/unistd.h 2.5.0-reserved/include/asm-i386/unistd.h
--- 2.5.0-pristine/include/asm-i386/unistd.h Thu Oct 18 03:03:03 2001
+++ 2.5.0-reserved/include/asm-i386/unistd.h Tue Dec 4 11:58:21 2001
@@ -230,6 +230,18 @@
#define __NR_security 223 /* syscall for security modules */
#define __NR_gettid 224
#define __NR_readahead 225
+#define __NR_setxattr 226
+#define __NR_lsetxattr 227
+#define __NR_fsetxattr 228
+#define __NR_getxattr 229
+#define __NR_lgetxattr 230
+#define __NR_fgetxattr 231
+#define __NR_listxattr 232
+#define __NR_llistxattr 233
+#define __NR_flistxattr 234
+#define __NR_removexattr 235
+#define __NR_lremovexattr 236
+#define __NR_fremovexattr 237
/* user-visible error numbers are in the range -1 - -124: see <asm-i386/errno.h> */
[2nd patch]
diff -Naur 2.5.0-pristine/arch/i386/kernel/entry.S 2.5.0-xattr/arch/i386/kernel/entry.S
--- 2.5.0-pristine/arch/i386/kernel/entry.S Sat Nov 3 12:18:49 2001
+++ 2.5.0-xattr/arch/i386/kernel/entry.S Tue Dec 4 12:02:56 2001
@@ -622,6 +622,18 @@
.long SYMBOL_NAME(sys_ni_syscall) /* Reserved for Security */
.long SYMBOL_NAME(sys_gettid)
.long SYMBOL_NAME(sys_readahead) /* 225 */
+ .long SYMBOL_NAME(sys_setxattr)
+ .long SYMBOL_NAME(sys_lsetxattr)
+ .long SYMBOL_NAME(sys_fsetxattr)
+ .long SYMBOL_NAME(sys_getxattr)
+ .long SYMBOL_NAME(sys_lgetxattr) /* 230 */
+ .long SYMBOL_NAME(sys_fgetxattr)
+ .long SYMBOL_NAME(sys_listxattr)
+ .long SYMBOL_NAME(sys_llistxattr)
+ .long SYMBOL_NAME(sys_flistxattr)
+ .long SYMBOL_NAME(sys_removexattr) /* 235 */
+ .long SYMBOL_NAME(sys_lremovexattr)
+ .long SYMBOL_NAME(sys_fremovexattr)
.rept NR_syscalls-(.-sys_call_table)/4
.long SYMBOL_NAME(sys_ni_syscall)
diff -Naur 2.5.0-pristine/fs/Makefile 2.5.0-xattr/fs/Makefile
--- 2.5.0-pristine/fs/Makefile Tue Nov 13 04:34:16 2001
+++ 2.5.0-xattr/fs/Makefile Fri Nov 30 15:33:28 2001
@@ -14,7 +14,7 @@
super.o block_dev.o char_dev.o stat.o exec.o pipe.o namei.o \
fcntl.o ioctl.o readdir.o select.o fifo.o locks.o \
dcache.o inode.o attr.o bad_inode.o file.o iobuf.o dnotify.o \
- filesystems.o namespace.o seq_file.o
+ filesystems.o namespace.o seq_file.o xattr.o
ifeq ($(CONFIG_QUOTA),y)
obj-y += dquot.o
diff -Naur 2.5.0-pristine/fs/xattr.c 2.5.0-xattr/fs/xattr.c
--- 2.5.0-pristine/fs/xattr.c Thu Jan 1 10:00:00 1970
+++ 2.5.0-xattr/fs/xattr.c Tue Dec 4 12:00:49 2001
@@ -0,0 +1,346 @@
+/*
+ File: fs/xattr.c
+
+ Extended attribute handling.
+
+ Copyright (C) 2001 by Andreas Gruenbacher <a.gruenbacher@computer.org>
+ Copyright (C) 2001 SGI - Silicon Graphics, Inc <linux-xfs@oss.sgi.com>
+ */
+#include <linux/fs.h>
+#include <linux/slab.h>
+#include <linux/vmalloc.h>
+#include <linux/smp_lock.h>
+#include <linux/file.h>
+#include <linux/xattr.h>
+#include <asm/uaccess.h>
+
+/*
+ * Extended attribute memory allocation wrappers, originally
+ * based on the Intermezzo PRESTO_ALLOC/PRESTO_FREE macros.
+ * The vmalloc use here is very uncommon - extended attributes
+ * are supposed to be small chunks of metadata, and it is quite
+ * unusual to have very many extended attributes, so lists tend
+ * to be quite short as well. The 64K upper limit is derived
+ * from the extended attribute size limit used by XFS.
+ * Intentionally allow zero @size for value/list size requests.
+ */
+static void *
+xattr_alloc(size_t size, size_t limit)
+{
+ void *ptr;
+
+ if (size > limit)
+ return ERR_PTR(-E2BIG);
+
+ if (!size) /* size request, no buffer is needed */
+ return NULL;
+ else if (size <= PAGE_SIZE)
+ ptr = kmalloc((unsigned long) size, GFP_KERNEL);
+ else
+ ptr = vmalloc((unsigned long) size);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+ return ptr;
+}
+
+static void
+xattr_free(void *ptr, size_t size)
+{
+ if (!size) /* size request, no buffer was needed */
+ return;
+ else if (size <= PAGE_SIZE)
+ kfree(ptr);
+ else
+ vfree(ptr);
+}
+
+/*
+ * Extended attribute SET operations
+ */
+static long
+setxattr(struct dentry *d, char *name, void *value, size_t size, int flags)
+{
+ int error;
+ void *kvalue;
+ char kname[XATTR_NAME_MAX + 1];
+
+ error = -EINVAL;
+ if (flags & ~(XATTR_CREATE|XATTR_REPLACE))
+ return error;
+
+ error = -EFAULT;
+ if (copy_from_user(kname, name, XATTR_NAME_MAX))
+ return error;
+ kname[XATTR_NAME_MAX] = '\0';
+
+ kvalue = xattr_alloc(size, XATTR_SIZE_MAX);
+ if (IS_ERR(kvalue))
+ return PTR_ERR(kvalue);
+
+ error = -EFAULT;
+ if (size > 0 && copy_from_user(kvalue, value, size)) {
+ xattr_free(kvalue, size);
+ return error;
+ }
+
+ error = -EOPNOTSUPP;
+ if (d->d_inode->i_op && d->d_inode->i_op->setxattr) {
+ lock_kernel();
+ error = d->d_inode->i_op->setxattr(d, kname, kvalue, size, flags);
+ unlock_kernel();
+ }
+
+ xattr_free(kvalue, size);
+ return error;
+}
+
+asmlinkage long
+sys_setxattr(char *path, char *name, void *value, size_t size, int flags)
+{
+ struct nameidata nd;
+ int error;
+
+ error = user_path_walk(path, &nd);
+ if (error)
+ return error;
+ error = setxattr(nd.dentry, name, value, size, flags);
+ path_release(&nd);
+ return error;
+}
+
+asmlinkage long
+sys_lsetxattr(char *path, char *name, void *value, size_t size, int flags)
+{
+ struct nameidata nd;
+ int error;
+
+ error = user_path_walk_link(path, &nd);
+ if (error)
+ return error;
+ error = setxattr(nd.dentry, name, value, size, flags);
+ path_release(&nd);
+ return error;
+}
+
+asmlinkage long
+sys_fsetxattr(int fd, char *name, void *value, size_t size, int flags)
+{
+ struct file *f;
+ int error = -EBADF;
+
+ f = fget(fd);
+ if (!f)
+ return error;
+ error = setxattr(f->f_dentry, name, value, size, flags);
+ fput(f);
+ return error;
+}
+
+/*
+ * Extended attribute GET operations
+ */
+static long
+getxattr(struct dentry *d, char *name, void *value, size_t size)
+{
+ int error;
+ void *kvalue;
+ char kname[XATTR_NAME_MAX + 1];
+
+ error = -EFAULT;
+ if (copy_from_user(kname, name, XATTR_NAME_MAX))
+ return error;
+ kname[XATTR_NAME_MAX] = '\0';
+
+ kvalue = xattr_alloc(size, XATTR_SIZE_MAX);
+ if (IS_ERR(kvalue))
+ return PTR_ERR(kvalue);
+
+ error = -EOPNOTSUPP;
+ if (d->d_inode->i_op && d->d_inode->i_op->getxattr) {
+ lock_kernel();
+ error = d->d_inode->i_op->getxattr(d, kname, kvalue, size);
+ unlock_kernel();
+ }
+
+ if (kvalue && error > 0)
+ if (copy_to_user(value, kvalue, size))
+ error = -EFAULT;
+ xattr_free(kvalue, size);
+ return error;
+}
+
+asmlinkage long
+sys_getxattr(char *path, char *name, void *value, size_t size)
+{
+ struct nameidata nd;
+ int error;
+
+ error = user_path_walk(path, &nd);
+ if (error)
+ return error;
+ error = getxattr(nd.dentry, name, value, size);
+ path_release(&nd);
+ return error;
+}
+
+asmlinkage long
+sys_lgetxattr(char *path, char *name, void *value, size_t size)
+{
+ struct nameidata nd;
+ int error;
+
+ error = user_path_walk_link(path, &nd);
+ if (error)
+ return error;
+ error = getxattr(nd.dentry, name, value, size);
+ path_release(&nd);
+ return error;
+}
+
+asmlinkage long
+sys_fgetxattr(int fd, char *name, void *value, size_t size)
+{
+ struct file *f;
+ int error = -EBADF;
+
+ f = fget(fd);
+ if (!f)
+ return error;
+ error = getxattr(f->f_dentry, name, value, size);
+ fput(f);
+ return error;
+}
+
+/*
+ * Extended attribute LIST operations
+ */
+static long
+listxattr(struct dentry *d, char *list, size_t size)
+{
+ int error;
+ char *klist;
+
+ klist = (char *)xattr_alloc(size, XATTR_LIST_MAX);
+ if (IS_ERR(klist))
+ return PTR_ERR(klist);
+
+ error = -EOPNOTSUPP;
+ if (d->d_inode->i_op && d->d_inode->i_op->listxattr) {
+ lock_kernel();
+ error = d->d_inode->i_op->listxattr(d, klist, size);
+ unlock_kernel();
+ }
+
+ if (klist && error > 0)
+ if (copy_to_user(list, klist, size))
+ error = -EFAULT;
+ xattr_free(klist, size);
+ return error;
+}
+
+asmlinkage long
+sys_listxattr(char *path, char *list, size_t size)
+{
+ struct nameidata nd;
+ int error;
+
+ error = user_path_walk(path, &nd);
+ if (error)
+ return error;
+ error = listxattr(nd.dentry, list, size);
+ path_release(&nd);
+ return error;
+}
+
+asmlinkage long
+sys_llistxattr(char *path, char *list, size_t size)
+{
+ struct nameidata nd;
+ int error;
+
+ error = user_path_walk_link(path, &nd);
+ if (error)
+ return error;
+ error = listxattr(nd.dentry, list, size);
+ path_release(&nd);
+ return error;
+}
+
+asmlinkage long
+sys_flistxattr(int fd, char *list, size_t size)
+{
+ struct file *f;
+ int error = -EBADF;
+
+ f = fget(fd);
+ if (!f)
+ return error;
+ error = listxattr(f->f_dentry, list, size);
+ fput(f);
+ return error;
+}
+
+/*
+ * Extended attribute REMOVE operations
+ */
+static long
+removexattr(struct dentry *d, char *name)
+{
+ int error;
+ char kname[XATTR_NAME_MAX + 1];
+
+ error = -EFAULT;
+ if (copy_from_user(kname, name, XATTR_NAME_MAX))
+ return error;
+ kname[XATTR_NAME_MAX] = '\0';
+
+ error = -EOPNOTSUPP;
+ if (d->d_inode->i_op && d->d_inode->i_op->removexattr) {
+ lock_kernel();
+ error = d->d_inode->i_op->removexattr(d, kname);
+ unlock_kernel();
+ }
+ return error;
+}
+
+asmlinkage long
+sys_removexattr(char *path, char *name)
+{
+ struct nameidata nd;
+ int error;
+
+ error = user_path_walk(path, &nd);
+ if (error)
+ return error;
+ error = removexattr(nd.dentry, name);
+ path_release(&nd);
+ return error;
+}
+
+asmlinkage long
+sys_lremovexattr(char *path, char *name)
+{
+ struct nameidata nd;
+ int error;
+
+ error = user_path_walk_link(path, &nd);
+ if (error)
+ return error;
+ error = removexattr(nd.dentry, name);
+ path_release(&nd);
+ return error;
+}
+
+asmlinkage long
+sys_fremovexattr(int fd, char *name)
+{
+ struct file *f;
+ int error = -EBADF;
+
+ f = fget(fd);
+ if (!f)
+ return error;
+ error = removexattr(f->f_dentry, name);
+ fput(f);
+ return error;
+}
diff -Naur 2.5.0-pristine/include/asm-i386/unistd.h 2.5.0-xattr/include/asm-i386/unistd.h
--- 2.5.0-pristine/include/asm-i386/unistd.h Thu Oct 18 03:03:03 2001
+++ 2.5.0-xattr/include/asm-i386/unistd.h Tue Dec 4 12:03:22 2001
@@ -230,6 +230,18 @@
#define __NR_security 223 /* syscall for security modules */
#define __NR_gettid 224
#define __NR_readahead 225
+#define __NR_setxattr 226
+#define __NR_lsetxattr 227
+#define __NR_fsetxattr 228
+#define __NR_getxattr 229
+#define __NR_lgetxattr 230
+#define __NR_fgetxattr 231
+#define __NR_listxattr 232
+#define __NR_llistxattr 233
+#define __NR_flistxattr 234
+#define __NR_removexattr 235
+#define __NR_lremovexattr 236
+#define __NR_fremovexattr 237
/* user-visible error numbers are in the range -1 - -124: see <asm-i386/errno.h> */
diff -Naur 2.5.0-pristine/include/linux/fs.h 2.5.0-xattr/include/linux/fs.h
--- 2.5.0-pristine/include/linux/fs.h Fri Nov 23 06:46:19 2001
+++ 2.5.0-xattr/include/linux/fs.h Tue Dec 4 12:03:34 2001
@@ -851,6 +851,10 @@
int (*revalidate) (struct dentry *);
int (*setattr) (struct dentry *, struct iattr *);
int (*getattr) (struct dentry *, struct iattr *);
+ int (*setxattr) (struct dentry *, char *, void *, size_t, int);
+ int (*getxattr) (struct dentry *, char *, void *, size_t);
+ int (*listxattr) (struct dentry *, char *, size_t);
+ int (*removexattr) (struct dentry *, char *);
};
/*
diff -Naur 2.5.0-pristine/include/linux/limits.h 2.5.0-xattr/include/linux/limits.h
--- 2.5.0-pristine/include/linux/limits.h Thu Jul 29 03:30:10 1999
+++ 2.5.0-xattr/include/linux/limits.h Fri Nov 30 15:33:28 2001
@@ -13,6 +13,9 @@
#define NAME_MAX 255 /* # chars in a file name */
#define PATH_MAX 4095 /* # chars in a path name */
#define PIPE_BUF 4096 /* # bytes in atomic write to a pipe */
+#define XATTR_NAME_MAX 255 /* # chars in an extended attribute name */
+#define XATTR_SIZE_MAX 65536 /* size of an extended attribute value (64k) */
+#define XATTR_LIST_MAX 65536 /* size of extended attribute namelist (64k) */
#define RTSIG_MAX 32
diff -Naur 2.5.0-pristine/include/linux/xattr.h 2.5.0-xattr/include/linux/xattr.h
--- 2.5.0-pristine/include/linux/xattr.h Thu Jan 1 10:00:00 1970
+++ 2.5.0-xattr/include/linux/xattr.h Tue Dec 4 12:01:35 2001
@@ -0,0 +1,15 @@
+/*
+ File: linux/xattr.h
+
+ Extended attributes handling.
+
+ Copyright (C) 2001 by Andreas Gruenbacher <a.gruenbacher@computer.org>
+ Copyright (C) 2001 SGI - Silicon Graphics, Inc <linux-xfs@oss.sgi.com>
+*/
+#ifndef _LINUX_XATTR_H
+#define _LINUX_XATTR_H
+
+#define XATTR_CREATE 0x1 /* set value, fail if attr already exists */
+#define XATTR_REPLACE 0x2 /* set value, fail if attr does not exist */
+
+#endif /* _LINUX_XATTR_H */
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Revised extended attributes interface
2001-12-05 3:32 [PATCH] Revised extended attributes interface Nathan Scott
@ 2001-12-07 20:20 ` Stephen C. Tweedie
2001-12-08 4:58 ` Nathan Scott
0 siblings, 1 reply; 8+ messages in thread
From: Stephen C. Tweedie @ 2001-12-07 20:20 UTC (permalink / raw)
To: Nathan Scott
Cc: Linus Torvalds, Alexander Viro, Andi Kleen, Andreas Gruenbacher,
linux-kernel, linux-fsdevel, linux-xfs, Stephen Tweedie
Hi,
On Wed, Dec 05, 2001 at 02:32:10PM +1100, Nathan Scott wrote:
> Here is the revised interface. I believe it takes into account
> the issues raised so far - further suggestions are also welcome,
> of course.
This is looking OK as far as EAs go. However, there is still no
mention of ACLs specifically, except an oblique reference to
""system.posix_acl_access".
Is there no consensus on this? In previous proposals we've at least
tried to deal with it to some extent.
Cheers,
Stephen
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Revised extended attributes interface
2001-12-07 20:20 ` Stephen C. Tweedie
@ 2001-12-08 4:58 ` Nathan Scott
2001-12-08 20:17 ` Hans Reiser
0 siblings, 1 reply; 8+ messages in thread
From: Nathan Scott @ 2001-12-08 4:58 UTC (permalink / raw)
To: Stephen C . Tweedie, Andreas Gruenbacher
Cc: linux-kernel, linux-fsdevel, linux-xfs
On Fri, Dec 07, 2001 at 08:20:36PM +0000, Stephen C. Tweedie wrote:
> Hi,
>
hi Stephen,
> This is looking OK as far as EAs go. However, there is still no
> mention of ACLs specifically, except an oblique reference to
> "system.posix_acl_access".
Yup - there's little mention of ACLs because they are only an
optional, higher-level consumer of the API, & so didn't seem
appropriate to document here.
We have implemented POSIX ACLs above this interface - there
is source to new versions of Andreas' user tools here:
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/acl2
These have been tested with XFS and seem to work fine, so we
are ready to transition over from our old implementation to
this new one.
In a way there's consensus wrt how to do POSIX ACLs on Linux
now, as both the ext2/ext3 and XFS ACL projects will be using
the same tools, libraries, etc. In terms of other ACL types,
I don't know of anyone actively working on any.
The existence of a POSIX ACL implementation using attributes
system.posix_acl_access and system.posix_acl_default doesn't
preclude other types of ACLs from being implemented (obviously
using different attributes) as well of course, if someone had
an itch to scratch.
cheers.
--
Nathan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Revised extended attributes interface
2001-12-08 4:58 ` Nathan Scott
@ 2001-12-08 20:17 ` Hans Reiser
2001-12-11 2:42 ` reiser4 (was Re: [PATCH] Revised extended attributes interface) Nathan Scott
0 siblings, 1 reply; 8+ messages in thread
From: Hans Reiser @ 2001-12-08 20:17 UTC (permalink / raw)
To: Nathan Scott
Cc: Stephen C . Tweedie, Andreas Gruenbacher, linux-kernel,
linux-fsdevel, linux-xfs
Nathan Scott wrote:
>
>
>In a way there's consensus wrt how to do POSIX ACLs on Linux
>now, as both the ext2/ext3 and XFS ACL projects will be using
>the same tools, libraries, etc. In terms of other ACL types,
>I don't know of anyone actively working on any.
>
>
We are taking a very different approach to EAs (and thus to ACLs) as
described in brief at www.namesys.com/v4/v4.html. We don't expect
anyone to take us seriously on it before it works, but silence while
coding does not equal consensus.;-)
In essence, we think that if a file can't do what an EA can do, then you
need to make files able to do more.
It is very important not to reduce the amount of closure (as in
mathematical closure) within the namespace, and creating EAs that cannot
be accessed as files reduces closure.
The same argument applies to streams, but it is kind of interesting to
see people argue against streams for this reason, and then embrace EAs.
Kind of leaves you wondering whether their hatred of streams was really
any deeper than streams aren't what they are used to from Unix.
Hans
^ permalink raw reply [flat|nested] 8+ messages in thread
* reiser4 (was Re: [PATCH] Revised extended attributes interface)
2001-12-08 20:17 ` Hans Reiser
@ 2001-12-11 2:42 ` Nathan Scott
2001-12-11 19:23 ` Anton Altaparmakov
0 siblings, 1 reply; 8+ messages in thread
From: Nathan Scott @ 2001-12-11 2:42 UTC (permalink / raw)
To: Hans Reiser, Andreas Gruenbacher; +Cc: linux-kernel, linux-fsdevel, linux-xfs
hi Hans,
On Sat, Dec 08, 2001 at 11:17:21PM +0300, Hans Reiser wrote:
> Nathan Scott wrote:
> >
> >In a way there's consensus wrt how to do POSIX ACLs on Linux
> >now, as both the ext2/ext3 and XFS ACL projects will be using
> >the same tools, libraries, etc. In terms of other ACL types,
> >I don't know of anyone actively working on any.
> >
> We are taking a very different approach to EAs (and thus to ACLs) as
> described in brief at www.namesys.com/v4/v4.html. We don't expect
> anyone to take us seriously on it before it works, but silence while
> coding does not equal consensus.;-)
>
> In essence, we think that if a file can't do what an EA can do, then you
> need to make files able to do more.
We did read through your page awhile ago. It wasn't clear to me
how you were addressing Anton's questions here:
http://marc.theaimsgroup.com/?l=linux-fsdevel&m=97260371413867&w=2
(I couldn't find a reply in the archive, but may have missed it).
We were concentrating on something that could be fs-independent,
so the lack of answers there put us off a bit, and the dependence
on a reiser4() syscall is pretty filesystem-specific too (I guess
if your solution is intended to be a reiserfs-specific one, then
the questions above are meaningless).
I was curious on another thing also - in the section titled
``The Usual Resolution Of These Flaws Is A One-Off Solution'',
talking about security attributes interfaces, your page says:
"Linus said that we can have a system call to use as our
experimental plaything in this. With what I have in mind for the
API, one rather flexible system call is all we want..."
How did you manage to get him to say that? We were flamed for
suggesting a syscall which multiplexed all extended attributes
commands though the one interface (because its semantics were
not clearly defined & it could be extended with new commands,
like ioctl/quotactl/...), and we've also had no luck so far in
getting either our original interface, nor any revised syscall
interfaces (which aren't like that anymore) accepted by Linus.
many thanks.
--
Nathan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: reiser4 (was Re: [PATCH] Revised extended attributes interface)
2001-12-11 2:42 ` reiser4 (was Re: [PATCH] Revised extended attributes interface) Nathan Scott
@ 2001-12-11 19:23 ` Anton Altaparmakov
2001-12-11 21:21 ` Hans Reiser
0 siblings, 1 reply; 8+ messages in thread
From: Anton Altaparmakov @ 2001-12-11 19:23 UTC (permalink / raw)
To: Hans Reiser
Cc: Nathan Scott, Andreas Gruenbacher, linux-kernel, linux-fsdevel,
linux-xfs
Hi Hans,
At 12:02 11/12/01, Hans Reiser wrote:
> I respond below.
>
>I didn't see that email, probably because I was not on the cc list.
>
>Nathan Scott wrote:
>>hi Hans,
>>On Sat, Dec 08, 2001 at 11:17:21PM +0300, Hans Reiser wrote:
>>>Nathan Scott wrote:
>>>>In a way there's consensus wrt how to do POSIX ACLs on Linux
>>>>now, as both the ext2/ext3 and XFS ACL projects will be using
>>>>the same tools, libraries, etc. In terms of other ACL types,
>>>>I don't know of anyone actively working on any.
>>>We are taking a very different approach to EAs (and thus to ACLs) as
>>>described in brief at www.namesys.com/v4/v4.html. We don't expect
>>>anyone to take us seriously on it before it works, but silence while
>>>coding does not equal consensus.;-)
>>>
>>>In essence, we think that if a file can't do what an EA can do, then you
>>>need to make files able to do more.
>>We did read through your page awhile ago. It wasn't clear to me
>>how you were addressing Anton's questions here:
>>http://marc.theaimsgroup.com/?l=linux-fsdevel&m=97260371413867&w=2
>>(I couldn't find a reply in the archive, but may have missed it).
>>
>>We were concentrating on something that could be fs-independent,
>>so the lack of answers there put us off a bit, and the dependence
>>on a reiser4() syscall is pretty filesystem-specific too (I guess
>>if your solution is intended to be a reiserfs-specific one, then
>>the questions above are meaningless).
>Changing the name of the system call is not a biggie. Our approach is to make
>it work for reiserfs, then proselytize. While we work, we let people know
>what we are working on, and if they join in, great to have it work for more
>than one FS.
>
>>I was curious on another thing also - in the section titled ``The Usual
>>Resolution Of These Flaws Is A One-Off Solution'',
>>talking about security attributes interfaces, your page says:
>>
>> "Linus said that we can have a system call to use as
>> our*experimental plaything in this. With what I have in mind for the
>>API, one rather flexible system call is all we want..."
>>
>>How did you manage to get him to say that? We were flamed for
>>suggesting a syscall which multiplexed all extended attributes
>>commands though the one interface (because its semantics were
>>not clearly defined & it could be extended with new commands,
>>like ioctl/quotactl/...), and we've also had no luck so far in
>>getting either our original interface, nor any revised syscall
>>interfaces (which aren't like that anymore) accepted by Linus.*
>
>We expect to get flamed once we have a patch.;-) When we
>have something mature enough to be usable, I expect he'll find a lot that
>could be made better. He does that.;-)
>
>For us, there are semantic advantages to having a single system call. Probably
>it will get a lot of argument once we have working code, and frankly I prefer
>to have that argument only after it is something usable, and it is easy to see
>the convenience of expression that comes from it. We want to Linux to be
>MORE expressive than BeOS in regards to files.
>
>>*
>>many thanks.
>>*
>>**
> **
>*
>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 wrote:
>No, it is _not_ goodness, IMHO. - If you did implement the API for
>attributes through files and directories, then what would you do with
>named streams?!?
>*
> **
>**
>
>*Hans Reiser wrote:
>
>What is your intended functional difference between extended attributes
>and streams?
>
>None?
Differences in NTFS:
- maximum size (EA limited to 64kiB, named stream 2^63 bytes)
- locality of storage (all EAs are stored in one so they are quicker to
access when you need to access multiple EAs)
- name namespace (Unicode names for named streams vs ASCII for EAs)
- potential ability to compress/encrypt (EAs cannot do this, named streams
could possibly and they certainly can be sparse, too which EAs cannot be)
- named streams have creation/modification/access/etc times associated with
them, EAs don't
How is that for a start?
>Ok, let's assume none until I get your response. (I can respond more
>specifically
>after you correct me.) Let me further go out on a limb,and guess that you
>intend
>that extended attributes are meta-information about the object, and streams
>are contained within the object.
Streams are only within the inode if they are tiny, otherwise they are
stored indirect just like normal file data. What they contain is complete
specific to the creator. Same is valid for EAs, with the exception that all
EAs are stored as one "stream" (for lack of a better word).
>In this case, a naming convention is quite sufficient to distinguish them.
Still think so? I don't.
>Extended attributes can have names of the form filenameA/..extone.
>
>Streams can have names of the form filenameA/streamone.
>
>In other words, all meta-information about an object should by convention
>(and only by convention, because people should live free, and because
>there is not always an obvious distinction between meta and contained
>information) be preceded by '..'
>
>Note that readdir should return neither stream names nor extended
>attribute names,
>and the use of 'hidden' directory entries accomplishes this (ala .snapshot
>for WAFL).
>*
>**
> **
All the below quotes refering to *Curtis are actually from me, IIRC...
>*Curtis:
>You can't possibly have both using the same API since you would then get
>name collision on filesystems where both named streams and EAs are supported.
>*
> **
>**
>
>*Name distinctions are what you use to avoid name collisions, see above.
>*
Ok, that would work, BUT:
(Again this is me not Curtis...)
>*Curtis:
>(And I haven't even mentioned EAs and named streams attached to actual
>_real_ directories yet.)
>
>*
> **
>*I don't understand this.
Ok, I will try to explain. An inode is the real thing, not a file. An inode
can by definition be a file or a directory (or a symlink, or special device
file, etc).
Any of these (i.e. any inode) can have both named streams AND EAs attached
to them on NTFS. So say I have a directory named MyDir and it contains a
named stream called MyStream1 and an EA called MyEA1 and two files, one
called MyStream1 and one called "..MyEA1".
Now with your scheme of naming things, looking up MyDir/MyStream1 matches
both the file MyStream1 that is in the directory MyDir and the named stream
MyStream1 belonging to the directory MyDir. - How do you/does one
distinguish the two in your scheme?!? I can only see it makind a big BANG
here...
Similarly, looking up MyDir/..MyEA1 matches both the file named "..MyEA1"
and the EA MyEA1. BANG!
And add a named stream actually named "..MyEA1" to MyDir and you have total
salad!
See the problem now?
I certainly fail to see how your naming scheme is going to cope with
this... Perhaps I am missing something?
Now if you have distinct APIs for EAs you have no problems on that side and
if you don't use the slash but say the colon (like Windows does) for named
streams you get rid of the named streams in directories problem, too. But
then you need to forbid the ":" as an accepted character in the file name
just like Windows does which is probably a reason not to use that API either...
>*
>**
> **
>
>*Curtis:
>Let's face it: EAs exist. They are _not_ files/directories so the API
>*
> **
>*Is this an argument?
>
>EA's do not exist in Linux, and they should never exist as something that
>is more than a file. Since they do not exist, you might as well improve
>the filesystems you port to Linux while porting them. APIs shape an OS
>over the long term, and if done wrong they burden generations after you
>with crud.
Like Microsoft is going to let me change the NTFS specifications to modify
how EAs and named streams are stored. Dream on!
But perhaps we are talking past each other: I am talking on-disk format /
specifications. These exist and no, we cannot change those at all. You can
do that with reiserfs as it is yours but all of us supporting existing file
systems owned by corporations like Microsoft, SGI, etc, have to live with
the specifications.
>*
>**
> **
>*Curtis:
>should not make them appear as files/directories. - You have to consider
>that there are a lot of filesystems out there which are already developed
>and which need to be supported. - Not everyone has their own filesystem
>which they can change/extend the specifications/implementation of at will.
>*
> **
>*
>Yes they do. It is all GPL'd. Even XFS. Do the underlying infrastructure
>the right way, and I bet you'll be surprised at how little need there really
>is for ea's done the wrong way. A user space library can cover
>over it all (causing only the obsolete programs using it to suffer while they
>wait to fade away).
?!? GPL has nothing to do with on-disk format and I doubt Microsoft would
agree that the ntfs on-disk layout is GPL. It's a trade secret! Why do you
think ntfs developers have to spend half their life using disassemblers and
hexeditors?!?
>*
>What would have happened if set theory had not just sets and elements, but
>sets, elements, extended-attributes, and streams, and you could not use
>the same operators on streams that you use on elements? It would have
>been crap as a theoretical model. It does real damage when you add things
>that require different operators to the set of primitives. Closure is
>extremely important to design. Don't do this.
Since we are going into analogies: You don't use a hammer to affix a screw
and neither do you use a screwdriver to affix a nail...at least I don't. I
think you are trying to use a large sledge hammer to put together things
which do not fit together thus breaking them in the process. To use your
own words: Don't do this. (-; Each is distinct and should be treated as
such. </me ducks>
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/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: reiser4 (was Re: [PATCH] Revised extended attributes interface)
2001-12-11 19:23 ` Anton Altaparmakov
@ 2001-12-11 21:21 ` Hans Reiser
2001-12-13 1:43 ` Andrew Pimlott
0 siblings, 1 reply; 8+ messages in thread
From: Hans Reiser @ 2001-12-11 21:21 UTC (permalink / raw)
To: Anton Altaparmakov
Cc: Nathan Scott, Andreas Gruenbacher, linux-kernel, linux-fsdevel,
linux-xfs
Anton Altaparmakov wrote:
> Hi Hans,
>
> At 12:02 11/12/01, Hans Reiser wrote:
>
>> I respond below.
>>
>> I didn't see that email, probably because I was not on the cc list.
>>
>> Nathan Scott wrote:
>>
>>> hi Hans,
>>> On Sat, Dec 08, 2001 at 11:17:21PM +0300, Hans Reiser wrote:
>>>
>>>> Nathan Scott wrote:
>>>>
>>>>> In a way there's consensus wrt how to do POSIX ACLs on Linux
>>>>> now, as both the ext2/ext3 and XFS ACL projects will be using
>>>>> the same tools, libraries, etc. In terms of other ACL types,
>>>>> I don't know of anyone actively working on any.
>>>>
>>>> We are taking a very different approach to EAs (and thus to ACLs)
>>>> as described in brief at www.namesys.com/v4/v4.html. We don't
>>>> expect anyone to take us seriously on it before it works, but
>>>> silence while coding does not equal consensus.;-)
>>>>
>>>> In essence, we think that if a file can't do what an EA can do,
>>>> then you need to make files able to do more.
>>>
>>> We did read through your page awhile ago. It wasn't clear to me
>>> how you were addressing Anton's questions here:
>>> http://marc.theaimsgroup.com/?l=linux-fsdevel&m=97260371413867&w=2
>>> (I couldn't find a reply in the archive, but may have missed it).
>>>
>>> We were concentrating on something that could be fs-independent,
>>> so the lack of answers there put us off a bit, and the dependence
>>> on a reiser4() syscall is pretty filesystem-specific too (I guess
>>> if your solution is intended to be a reiserfs-specific one, then
>>> the questions above are meaningless).
>>
>> Changing the name of the system call is not a biggie. Our approach
>> is to make
>> it work for reiserfs, then proselytize. While we work, we let people
>> know
>> what we are working on, and if they join in, great to have it work
>> for more
>> than one FS.
>>
>>> I was curious on another thing also - in the section titled ``The
>>> Usual Resolution Of These Flaws Is A One-Off Solution'',
>>> talking about security attributes interfaces, your page says:
>>>
>>> "Linus said that we can have a system call to use as
>>> our*experimental plaything in this. With what I have in mind for the
>>> API, one rather flexible system call is all we want..."
>>>
>>> How did you manage to get him to say that? We were flamed for
>>> suggesting a syscall which multiplexed all extended attributes
>>> commands though the one interface (because its semantics were
>>> not clearly defined & it could be extended with new commands,
>>> like ioctl/quotactl/...), and we've also had no luck so far in
>>> getting either our original interface, nor any revised syscall
>>> interfaces (which aren't like that anymore) accepted by Linus.*
>>
>>
>> We expect to get flamed once we have a patch.;-) When we
>> have something mature enough to be usable, I expect he'll find a lot
>> that
>> could be made better. He does that.;-)
>>
>> For us, there are semantic advantages to having a single system call.
>> Probably
>> it will get a lot of argument once we have working code, and frankly
>> I prefer
>> to have that argument only after it is something usable, and it is
>> easy to see
>> the convenience of expression that comes from it. We want to Linux
>> to be
>> MORE expressive than BeOS in regards to files.
>>
>>> *
>>> many thanks.
>>> *
>>> **
>>
>> **
>> *
>> 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 wrote:
>
>> No, it is _not_ goodness, IMHO. - If you did implement the API for
>> attributes through files and directories, then what would you do with
>> named streams?!?
>> *
>> **
>> **
>>
>> *Hans Reiser wrote:
>>
>> What is your intended functional difference between extended
>> attributes and streams?
>>
>> None?
>
>
> Differences in NTFS:
>
> - maximum size (EA limited to 64kiB, named stream 2^63 bytes)
These are desirable limits to preserve? For sure? If so, then a
particular plugin can be written to restrict files to 64k, though I
shake my head at the thought.
>
> - locality of storage (all EAs are stored in one so they are quicker
> to access when you need to access multiple EAs)
arbitrarily aggregating files is a useful feature, there is no reason to
rigidly offer and require the feature for EAs only.
>
> - name namespace (Unicode names for named streams vs ASCII for EAs)
Namespaces can be changed for the children of directories. Plan9 guys
have done such things, and it is cool.
>
> - potential ability to compress/encrypt (EAs cannot do this, named
> streams could possibly and they certainly can be sparse, too which EAs
> cannot be)
Well, I suppose you could allow restricting some files to not have
compression and sparseness, though it isn't exciting to me.
>
> - named streams have creation/modification/access/etc times associated
> with them, EAs don't
I thought streams shared the stat data of the parent file?
Regardless, files should be able to share/inherit stat data.
>
>
> How is that for a start?
Not one reason cited is convincing to me.
>
>
>> Ok, let's assume none until I get your response. (I can respond more
>> specifically
>> after you correct me.) Let me further go out on a limb,and guess
>> that you intend
>> that extended attributes are meta-information about the object, and
>> streams
>> are contained within the object.
>
>
> Streams are only within the inode if they are tiny, otherwise they are
> stored indirect just like normal file data. What they contain is
> complete specific to the creator. Same is valid for EAs, with the
> exception that all EAs are stored as one "stream" (for lack of a
> better word).
I miss the point of the implementation details cited above.
>
>
>> In this case, a naming convention is quite sufficient to distinguish
>> them.
>
>
> Still think so?
Yes.
> I don't.
>
>> Extended attributes can have names of the form filenameA/..extone.
>>
>> Streams can have names of the form filenameA/streamone.
>>
>> In other words, all meta-information about an object should by
>> convention
>> (and only by convention, because people should live free, and because
>> there is not always an obvious distinction between meta and contained
>> information) be preceded by '..'
>>
>> Note that readdir should return neither stream names nor extended
>> attribute names,
>> and the use of 'hidden' directory entries accomplishes this (ala
>> .snapshot
>> for WAFL).
>> *
>> **
>> **
>
>
> All the below quotes refering to *Curtis are actually from me, IIRC...
>
>> *Curtis:
>> You can't possibly have both using the same API since you would then
>> get name collision on filesystems where both named streams and EAs
>> are supported.
>> *
>> **
>> **
>>
>> *Name distinctions are what you use to avoid name collisions, see above.
>> *
>
>
> Ok, that would work, BUT:
>
> (Again this is me not Curtis...)
>
>> *Curtis:
>> (And I haven't even mentioned EAs and named streams attached to
>> actual _real_ directories yet.)
>>
>> *
>> **
>> *I don't understand this.
>
>
> Ok, I will try to explain. An inode is the real thing, not a file.
In reiserfs we say object, and consider files and directories (and
symlinks, etc.) to be objects. We don't have on-disk inodes. Inodes
are implementation layer not semantic layer. We should be talking about
semantic layer here I think.
> An inode can by definition be a file or a directory (or a symlink, or
> special device file, etc).
>
> Any of these (i.e. any inode) can have both named streams AND EAs
> attached to them on NTFS. So say I have a directory named MyDir and it
> contains a named stream called MyStream1 and an EA called MyEA1 and
> two files, one called MyStream1 and one called "..MyEA1".
>
> Now with your scheme of naming things, looking up MyDir/MyStream1
> matches both the file MyStream1 that is in the directory MyDir and the
> named stream MyStream1 belonging to the directory MyDir. - How do
> you/does one distinguish the two in your scheme?!? I can only see it
> makind a big BANG here...
Well, gosh, okay, maybe you want to prepend ',,' to streams and '..' to
extended attributes. I personally think Linux would only want to do so
when used as a fileserver emulating NTFS/SAMBA. There is no enhancement
of user functionality from doing it for general purpose filesystems.
Feel free to substitute anything you like for ',,', the choice of
naming convention is not the point. You could even use ':':-).
It is important though that you not require ',,', ':', or '..' to have
these special meanings for all Linux namespaces, I hope that is understood.
>
>
> Similarly, looking up MyDir/..MyEA1 matches both the file named
> "..MyEA1" and the EA MyEA1. BANG!
>
> And add a named stream actually named "..MyEA1" to MyDir and you have
> total salad!
>
> See the problem now?
No, see above.
>
>
> I certainly fail to see how your naming scheme is going to cope with
> this... Perhaps I am missing something?
Naming conventions are easy. See above.
>
>
> Now if you have distinct APIs for EAs you have no problems on that
> side and if you don't use the slash but say the colon (like Windows
> does) for named streams you get rid of the named streams in
> directories problem, too. But then you need to forbid the ":" as an
> accepted character in the file name just like Windows does which is
> probably a reason not to use that API either...
>
>> *
>> **
>> **
>>
>> *Curtis:
>> Let's face it: EAs exist. They are _not_ files/directories so the API
>> *
>> **
>> *Is this an argument?
>>
>> EA's do not exist in Linux, and they should never exist as something
>> that is more than a file. Since they do not exist, you might as well
>> improve the filesystems you port to Linux while porting them. APIs
>> shape an OS over the long term, and if done wrong they burden
>> generations after you with crud.
>
>
> Like Microsoft is going to let me change the NTFS specifications to
> modify how EAs and named streams are stored. Dream on!
>
> But perhaps we are talking past each other: I am talking on-disk
> format / specifications.
I am NOT talking about on-disk format, I am talking about APIs and
naming conventions. On disk format is entirely FS specific. Live free
(errr, no, you are doing NTFS, live confined;-) ).....
> These exist and no, we cannot change those at all. You can do that
> with reiserfs as it is yours but all of us supporting existing file
> systems owned by corporations like Microsoft, SGI, etc, have to live
> with the specifications.
>
>> *
>> **
>> **
>> *Curtis:
>> should not make them appear as files/directories. - You have to
>> consider that there are a lot of filesystems out there which are
>> already developed and which need to be supported. - Not everyone has
>> their own filesystem which they can change/extend the
>> specifications/implementation of at will.
>> *
>> **
>> *
>> Yes they do. It is all GPL'd. Even XFS. Do the underlying
>> infrastructure
>> the right way, and I bet you'll be surprised at how little need there
>> really
>> is for ea's done the wrong way. A user space library can cover
>> over it all (causing only the obsolete programs using it to suffer
>> while they
>> wait to fade away).
>
>
> ?!? GPL has nothing to do with on-disk format and I doubt Microsoft
> would agree that the ntfs on-disk layout is GPL. It's a trade secret!
> Why do you think ntfs developers have to spend half their life using
> disassemblers and hexeditors?!?
Did you file comments in the various MS legal battles going on? You
should..... (I know, there is only a small chance it will have an
effect, but..... ) they should be required to give you the info, and if
you don't demand it I bet they won't be so required. Did you notice how
they are restricting things to only persons with a viable business in
the opinion of MS?
>
>
>> *
>> What would have happened if set theory had not just sets and
>> elements, but sets, elements, extended-attributes, and streams, and
>> you could not use the same operators on streams that you use on
>> elements? It would have been crap as a theoretical model. It does
>> real damage when you add things that require different operators to
>> the set of primitives. Closure is extremely important to design.
>> Don't do this.
>
>
> Since we are going into analogies: You don't use a hammer to affix a
> screw and neither do you use a screwdriver to affix a nail...at least
> I don't. I think you are trying to use a large sledge hammer to put
> together things which do not fit together thus breaking them in the
> process. To use your own words: Don't do this. (-; Each is distinct
> and should be treated as such. </me ducks>
>
> Best regards,
>
> Anton
>
>
Programs will get written to use your API, and not work with reiserfs,
and will get written to use our API and not work with NTFS, and this is
bad....
Thanks for the FS driver by the way, it is very useful to us dual-booters.
Hans
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: reiser4 (was Re: [PATCH] Revised extended attributes interface)
2001-12-11 21:21 ` Hans Reiser
@ 2001-12-13 1:43 ` Andrew Pimlott
2001-12-13 9:23 ` Hans Reiser
0 siblings, 1 reply; 8+ messages in thread
From: Andrew Pimlott @ 2001-12-13 1:43 UTC (permalink / raw)
To: Hans Reiser
Cc: Anton Altaparmakov, Nathan Scott, Andreas Gruenbacher,
linux-kernel, linux-fsdevel, linux-xfs
On Wed, Dec 12, 2001 at 12:21:49AM +0300, Hans Reiser wrote:
> Naming conventions are easy.
Hans,
While I look forward to your work, I think Anton points out some
issues that you really should try to address now, only you have not
understood them. Can I take a crack at posing some concrete
questions that manifest the issues?
Let's imagine that we have a Linux system with an NTFS filesystem
and a reiserfs4 filesystem. You can make any tentative assumptions
about reiserfs4 and new API's that you like, I just want to have an
idea of how you envision the following working:
First, I write a desktop application that wants to save an HTML file
along with some other object that contains the name of the creating
application. The latter can go anywhere you want, except in the
same stream as the HTML file. The user has requested that the
filename be /home/user/foo.html , and expects to be able to FTP this
file to his ISP with a standard FTP program. What calls does my
application make to store the HTML and the application name? If the
answer is different depending on whether /home/user is NTFS or
reiserfs4, explain both ways.
Second, I booted NT and created a directory in the NTFS filesystem
called /foo . In the directory, I created a file called bar. I
also created a named stream called bar, and an extended attribute
called bar. Now I boot Linux. What calls do I make to see each of
the three objects called bar?
The heart of Anton's argument is that the UNIX filesystem name space
is basically used up--there's just not much room to add new
semantics. The only obvious avenue for extension is, if /foo is not
a directory, you can give some interpretation to /foo/bar . But
this doesn't help if /foo is a directory. So something has to give,
and we want to see what will give in reiserfs4.
Andrew
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: reiser4 (was Re: [PATCH] Revised extended attributes interface)
2001-12-13 1:43 ` Andrew Pimlott
@ 2001-12-13 9:23 ` Hans Reiser
2001-12-13 10:36 ` User-manageable sub-ids proposals Romano Giannetti
0 siblings, 1 reply; 8+ messages in thread
From: Hans Reiser @ 2001-12-13 9:23 UTC (permalink / raw)
To: Andrew Pimlott
Cc: Anton Altaparmakov, Nathan Scott, Andreas Gruenbacher,
linux-kernel, linux-fsdevel, linux-xfs
Andrew Pimlott wrote:
>On Wed, Dec 12, 2001 at 12:21:49AM +0300, Hans Reiser wrote:
>
>>Naming conventions are easy.
>>
>
>Hans,
>
>While I look forward to your work, I think Anton points out some
>issues that you really should try to address now, only you have not
>understood them. Can I take a crack at posing some concrete
>questions that manifest the issues?
>
>Let's imagine that we have a Linux system with an NTFS filesystem
>and a reiserfs4 filesystem. You can make any tentative assumptions
>about reiserfs4 and new API's that you like, I just want to have an
>idea of how you envision the following working:
>
>First, I write a desktop application that wants to save an HTML file
>along with some other object that contains the name of the creating
>application. The latter can go anywhere you want, except in the
>same stream as the HTML file. The user has requested that the
>filename be /home/user/foo.html , and expects to be able to FTP this
>file to his ISP with a standard FTP program. What calls does my
>application make to store the HTML and the application name? If the
>answer is different depending on whether /home/user is NTFS or
>reiserfs4, explain both ways.
>
Are you sure that standard ftp will be able to handle extended
attributes without modification?
One approach is to create a plugin called ..archive that when read is a
virtual file consisting of an archive of everything in the directory.
It would be interesting I think to attach said plugin to standard
directories by default along with several other standard plugins like
..cat, etc.
>
>
>Second, I booted NT and created a directory in the NTFS filesystem
>called /foo . In the directory, I created a file called bar. I
>also created a named stream called bar, and an extended attribute
>called bar. Now I boot Linux. What calls do I make to see each of
>the three objects called bar?
>
You access /foo/bar, /foo/bar/,,bar, /foo/..bar by name.
>
>
>The heart of Anton's argument is that the UNIX filesystem name space
>is basically used up--there's just not much room to add new
>semantics. The only obvious avenue for extension is, if /foo is not
>a directory, you can give some interpretation to /foo/bar . But
>this doesn't help if /foo is a directory. So something has to give,
>and we want to see what will give in reiserfs4.
>
>Andrew
>
>
Naming conventions are easy, but teaching user space is hard no matter
whose scheme is used.
^ permalink raw reply [flat|nested] 8+ messages in thread
* User-manageable sub-ids proposals
2001-12-13 9:23 ` Hans Reiser
@ 2001-12-13 10:36 ` Romano Giannetti
2001-12-13 13:37 ` Ragnar Kjørstad
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Romano Giannetti @ 2001-12-13 10:36 UTC (permalink / raw)
To: linux-kernel
Good morning to everyone.
I was thinking about the idea of sub-ids to enable users to run "untrusted"
binary or "dangerous" one without risk for their files/privacy.
I had an idea to a low-profile, almost no invasive way to implement it that
should be almost transparent to user-space application (almost all). Let me
explain with an example.
Let's add to task_struct another array like groups[NGROUPS], calling it
slave_uids[NSLAVES]. Add a (privileged) syscall, addslave(uid_t, uid_t),
that can fill that arrays.
Now, the user space configuration is the following:
I am romano, uid 300.
There is(/are) another(s) user, for example r-slave, uid 3001, no login
shell, with home dir in ~romano/r-slave.
When I login as romano, the login binary call a addslave(300, 3001), looking
at a /etc/slaves that has a line that says romano:r-slave
Now change the kernel so that:
1) user romano can do a setuid() call to become anyone of its slaves, with
no way back possible.
2) user romano can chown() files owned by him and by any of its slaves to
any of the romano or slaves uids.
And that's all. All the other strange file management that user romano would
want to do on the slave-id environment, he can do by doing a kind-of-su(*)
to one of its slaves (with setuid) and then play in the restricted
enviroment. If you add ACL to this(**), you could easily fine-control what the
untrusted binary can see of your environment; add the per-vfsmount ro-flag
and it gives to you a lot of flexibility.
This should be a change simple enough for the kernel, and for the userspace
too: just change login to add addslave call, and the tools that need to
spawn untrusted binaries can do a setuid() to a slave before the exec().
Is there something that I am missing here?
Romano
(*) probably to be called giu... (sorry, Italian-speaking only joke: /su/
means 'up' in Italian, and /giu/ means 'down').
(**) and without ACL, if you makes a parallel thing for gid, you can
probably fine-tune access in the old-style ways, provided that the system
set-up is the "every user in its own group" style.
--
Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 411 132
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: User-manageable sub-ids proposals
2001-12-13 10:36 ` User-manageable sub-ids proposals Romano Giannetti
@ 2001-12-13 13:37 ` Ragnar Kjørstad
2001-12-13 16:06 ` Romano Giannetti
2001-12-18 0:17 ` Pavel Machek
2001-12-13 23:24 ` David Wagner
2001-12-21 21:28 ` Andreas Ferber
2 siblings, 2 replies; 8+ messages in thread
From: Ragnar Kjørstad @ 2001-12-13 13:37 UTC (permalink / raw)
To: Romano Giannetti, linux-kernel
On Thu, Dec 13, 2001 at 11:36:16AM +0100, Romano Giannetti wrote:
> I am romano, uid 300.
> There is(/are) another(s) user, for example r-slave, uid 3001, no login
> shell, with home dir in ~romano/r-slave.
It would be so much nicer to be able to do this on-the-fly, rather than
having to create the user and it's home directory first.
However, I think one must first start with figguring out what
functionality we want:
1 do we want the "slave" to be able to read the users files
2 do we want the "slave" to be able to write the users files
3 do we want the "slave" to keep is own configuration files
And I think the answers are:
1. No. It would make it possible for broken/evil programs
to steal your data.
2. Definitively not
3. No - it would cause different "slave" processes interact.
It should rather use the users regular configuration files.
And we end up with a different solution:
olduid=getuid();
/* Allocate a uid with no privilegies */
slaveuid=setruid_slave();
set_acl("private-file", ACL_READ, slaveuid);
set_acl("private-log", ACL_APPEND, slaveuid);
seteuid(slaveuid);
exec("dangerous-program");
This should also be possible to implement with minimal impact. All you
need is a new systemcall to allocate a uid for the slave. This means you
need to reserve some uids for this purpose, but with 32bit uids......
A possible addon would be a systemcall to free the uid when it was not
in use anymore, so it can be reused safely.
An alternative would be to not give the new uid access to the files, but
just open them before doing exec. This way it is safe to run multiple
slaves with the same uid at once, and it doesn't rely on ACLs! The
downside is that it needs cooperation from the dangerous-program, while
the above could work as long as the wrapper (e.g. a browser) took the
appropriate steps.
--
Ragnar Kjørstad
Big Storage
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: User-manageable sub-ids proposals
2001-12-13 13:37 ` Ragnar Kjørstad
@ 2001-12-13 16:06 ` Romano Giannetti
2001-12-13 18:58 ` Ragnar Kjørstad
2001-12-18 0:17 ` Pavel Machek
1 sibling, 1 reply; 8+ messages in thread
From: Romano Giannetti @ 2001-12-13 16:06 UTC (permalink / raw)
To: linux-kernel
On Thu, Dec 13, 2001 at 02:37:52PM +0100, Ragnar Kjørstad wrote:
> On Thu, Dec 13, 2001 at 11:36:16AM +0100, Romano Giannetti wrote:
> > I am romano, uid 300.
> > There is(/are) another(s) user, for example r-slave, uid 3001, no login
> > shell, with home dir in ~romano/r-slave.
>
> It would be so much nicer to be able to do this on-the-fly, rather than
> having to create the user and it's home directory first.
Yes, this could be nice.
> However, I think one must first start with figguring out what
> functionality we want:
> 1 do we want the "slave" to be able to read the users files
Yes, but _by default_ the slave process could read only the files that you
have world readable (or group readable, if the slave is in the same group
than you, which probably is not a good idea). So you could decide wich file
it can access and which not.
> 2 do we want the "slave" to be able to write the users files
Generally no, but you can create a dir where the slave uid can create file
(think to a java applet that need temporary files, etc...)
> 3 do we want the "slave" to keep is own configuration files
Define the slave uid to have the same home dir than the main user...
>
> This should also be possible to implement with minimal impact. All you
> need is a new systemcall to allocate a uid for the slave. This means you
> need to reserve some uids for this purpose, but with 32bit uids......
>
Yes, but then the slave process is very much _very_ limited. It could need
to read/map dynamic libraries, for example; with my approach the slave uid
processes are processes that have a full-level citizenship and that can do
anything a process can do, but under a different name than the user. Root
uses "nobody" to this extent sometime; my proposal is to extend this to
every (unprivileged) user in a safe way. Then, you can create a chrooted
environment for the new process and tailor the level of access it has
depending on the needs.
Romano
--
Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 411 132
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: User-manageable sub-ids proposals
2001-12-13 16:06 ` Romano Giannetti
@ 2001-12-13 18:58 ` Ragnar Kjørstad
0 siblings, 0 replies; 8+ messages in thread
From: Ragnar Kjørstad @ 2001-12-13 18:58 UTC (permalink / raw)
To: Romano Giannetti, linux-kernel
On Thu, Dec 13, 2001 at 05:06:29PM +0100, Romano Giannetti wrote:
> > 2 do we want the "slave" to be able to write the users files
>
> Generally no, but you can create a dir where the slave uid can create file
> (think to a java applet that need temporary files, etc...)
I think generally temporary files should go to /tmp and not the home
directory, but yes, there may be reasons to write to specific files in
the home directory as well.
> > This should also be possible to implement with minimal impact. All you
> > need is a new systemcall to allocate a uid for the slave. This means you
> > need to reserve some uids for this purpose, but with 32bit uids......
>
> Yes, but then the slave process is very much _very_ limited. It could need
> to read/map dynamic libraries, for example; with my approach the slave uid
> processes are processes that have a full-level citizenship and that can do
> anything a process can do, but under a different name than the user. Root
> uses "nobody" to this extent sometime; my proposal is to extend this to
> every (unprivileged) user in a safe way. Then, you can create a chrooted
> environment for the new process and tailor the level of access it has
> depending on the needs.
Why would the slave not be able to read/map dynamic libraries in my
sceeme? Such files should be readable by everyone, so I don't see the
problem?
With ACL support I don't see this beeing limited at all. The process can
be given any rights you desire before changing it's effective userid.
--
Ragnar Kjørstad
Big Storage
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: User-manageable sub-ids proposals
2001-12-13 13:37 ` Ragnar Kjørstad
2001-12-13 16:06 ` Romano Giannetti
@ 2001-12-18 0:17 ` Pavel Machek
1 sibling, 0 replies; 8+ messages in thread
From: Pavel Machek @ 2001-12-18 0:17 UTC (permalink / raw)
To: Ragnar Kjørstad; +Cc: Romano Giannetti, linux-kernel
Hi!
> And we end up with a different solution:
> olduid=getuid();
> /* Allocate a uid with no privilegies */
Dangerous. Imagine:
while (1) {
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: User-manageable sub-ids proposals
2001-12-13 10:36 ` User-manageable sub-ids proposals Romano Giannetti
2001-12-13 13:37 ` Ragnar Kjørstad
@ 2001-12-13 23:24 ` David Wagner
2001-12-21 21:28 ` Andreas Ferber
2 siblings, 0 replies; 8+ messages in thread
From: David Wagner @ 2001-12-13 23:24 UTC (permalink / raw)
To: linux-kernel
Romano Giannetti wrote:
>I was thinking about the idea of sub-ids to enable users to run "untrusted"
>binary or "dangerous" one without risk for their files/privacy.
Can I point you to some work I've done on this topic?
We built a tool called Janus (alas, it required kernel patches).
http://www.cs.berkeley.edu/~daw/janus/
Your basic goal seems like a good one: it'd be really nice if you could
run untrusted code in a sandbox that nothing can escape. Based on
our experience, though, I've come to believe you probably want a more
sophisticated solution than the one you outlined.
First, the 'nobody' userid (and equivalents) leave a lot to be desired.
A troubling number of system resources can be accessed by 'nobody': there
are usually an enormous quantity of world-readable files; more troubling,
there are tons of world-executable setuid programs, and it's hard with a
purely userid-based mechanism to be sure that they won't provide an escape
hatch; not to mention other resources, such as interprocess communication,
network sockets, and so on.
The conclusion we came to is that you really need something more powerful
than the existing access control measures. Unix systems are really not
very good at preventing attacks by local users.
A second claim is that you really want to start from the Principle
of Least Privilege: give the untrusted process the absolute minimum
privilege necessary for it to accomplish its task, and nothing more.
Userid-based mechanisms do a lousy job at achieving this.
This, by the way, is analogous to the "default deny" policy that you may
be familiar with from the firewalls world: if you start by giving the
untrusted process zero privileges and then explicitly declare only the
ones you want allowed, you greatly reduce the risk that the untrusted
process can escape and cause harm in some way you didn't expect.
A third observation is that you need to control access to a lot more
than just the filesystem. You want to control the network (prevent the
spread of viruses; and if anyone uses IP-based authentication, or if
your machine is inside a firewall, prevent the untrusted process from
abusing the good name of the local host). You want to control resources
like IPC, signals, resource usage, and so on. And I claim you want more
fine-grained control than POSIX capabilities provide.
A fourth observation is that in practice it's useful to provide more
than just isolation: you often also want to allow some limited degree
of sharing between trusted and untrusted processes. chroot() is not
so good in this respect, even apart from the fact that it protects only
the filesystem and not any of the other resources on the system.
The Janus approach is to interpose on system calls to impose a more
restrictive security policy. We use ptrace() and the like to do this
from userspace. It's a little clunky, especially since support for
process tracing on Linux has shortcomings, but it works. We've run
a web browser, a web server, etc., inside the restricted environment
Janus provides. Janus is just one approach, of course, and there are
a number of other projects that have followed related directions (DTE,
consh, mapbox, SubDomain, SELinux, etc.).
Looking to the future, may I direct your attention to the Linux Security
Module project? They're doing some great work that I think will lay
a fantastic foundation for trying out many different approaches to
this problem.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: User-manageable sub-ids proposals
2001-12-13 10:36 ` User-manageable sub-ids proposals Romano Giannetti
2001-12-13 13:37 ` Ragnar Kjørstad
2001-12-13 23:24 ` David Wagner
@ 2001-12-21 21:28 ` Andreas Ferber
2 siblings, 0 replies; 8+ messages in thread
From: Andreas Ferber @ 2001-12-21 21:28 UTC (permalink / raw)
To: Romano Giannetti, linux-kernel
On Thu, Dec 13, 2001 at 11:36:16AM +0100, Romano Giannetti wrote:
>
> I was thinking about the idea of sub-ids to enable users to run "untrusted"
> binary or "dangerous" one without risk for their files/privacy.
Most parts of your proposal can be implemented in userspace, without
any kernel changes.
In fact, most parts /are/ already implemented, and only waiting to be
configured properly. It's called "sudo".
The only deficiency of the userspace only approach I see at the moment
is that you can't impersonate the slave user from the main user id
regarding to filesystem access. This can be worked around with proper
permissions if you take the "one group/one user" approach, all
slave users will have the main users group.
Andreas
--
Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
---------------------------------------------------------
+49 521 1365800 - af@devcon.net - www.devcon.net
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2001-12-21 21:29 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-12-13 16:02 User-manageable sub-ids proposals Jacques Gelinas
-- strict thread matches above, loose matches on Subject: below --
2001-12-05 3:32 [PATCH] Revised extended attributes interface Nathan Scott
2001-12-07 20:20 ` Stephen C. Tweedie
2001-12-08 4:58 ` Nathan Scott
2001-12-08 20:17 ` Hans Reiser
2001-12-11 2:42 ` reiser4 (was Re: [PATCH] Revised extended attributes interface) Nathan Scott
2001-12-11 19:23 ` Anton Altaparmakov
2001-12-11 21:21 ` Hans Reiser
2001-12-13 1:43 ` Andrew Pimlott
2001-12-13 9:23 ` Hans Reiser
2001-12-13 10:36 ` User-manageable sub-ids proposals Romano Giannetti
2001-12-13 13:37 ` Ragnar Kjørstad
2001-12-13 16:06 ` Romano Giannetti
2001-12-13 18:58 ` Ragnar Kjørstad
2001-12-18 0:17 ` Pavel Machek
2001-12-13 23:24 ` David Wagner
2001-12-21 21:28 ` Andreas Ferber
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).