[ANNOUNCE][PATCH] New fs to control access to system resources

[ANNOUNCE][PATCH] New fs to control access to system resources

[Olaf Dietsche]

[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]

Hi,

this is a new file system to control access to system resources.
Currently it controls access to inet_bind() with ports < 1024 only.

With this patch, there's no need anymore to run internet daemons as
root. You can individually configure which user/program can bind to
ports below 1024.

For example, you can say, user www is allowed to bind to port 80 or
user mail is allowed to bind to port 25. Then, you can run apache as
user www and sendmail as user mail. Now, you don't have to rely on
apache or sendmail giving up superuser rights to enhance security.

To use this, you need to mount the file system and do a chown on the
appropriate ports:

# mount -t accessfs none /mnt
# chown www /mnt/net/ipv4/bind/80
# chown mail /mnt/net/ipv4/bind/25
...

You can grant access to a group for individual ports as well. Just say:

# chgrp lp /mnt/net/ipv4/bind/515
# chown g+x /mnt/net/ipv4/bind/515

... and you're done.

This patch is against 2.4.14, but it applies with offsets to 2.4.17
and 2.5.2 as well. However, I have built and tested 2.4.14 only.

Now, I would like to here from you, whether you find this useful or
not, have any suggestions, objections ... please tell me.
Of course, comments on the code are welcome too :-).

Thanks for your time.

Regards, Olaf.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: New linux accessfs --]
[-- Type: text/x-patch, Size: 14294 bytes --]

diff -X dontdiff -urN v2.4.14/Documentation/Configure.help linux/Documentation/Configure.help
--- v2.4.14/Documentation/Configure.help	Mon Nov  5 22:40:59 2001
+++ linux/Documentation/Configure.help	Fri Jan 11 21:45:16 2002
@@ -19179,6 +19179,34 @@
   To use this option, you have to check that the "/proc file system
   support" (CONFIG_PROC_FS) is enabled, too.
 
+Accessfs support (EXPERIMENTAL)
+CONFIG_ACCESS_FS
+  This is a new file system to control access to system resources.
+  Currently it controls access to bind() with ports < 1024 only.
+
+  With this file system, there's no need anymore to run internet daemons
+  as root. You can individually configure which user/program can bind to
+  ports below 1024.
+
+  For example, you can say, user www is allowed to bind to port 80 or
+  user mail is allowed to bind to port 25. Then, you can run apache as
+  user www and sendmail as user mail. Now, you don't have to rely on
+  apache or sendmail giving up superuser rights to enhance security.
+
+  To use this file system, you need to mount the file system somewhere
+  and do a chown on the appropriate ports:
+
+  # mount -t accessfs none /mnt
+  # chown www /mnt/net/ipv4/bind/80
+  # chown mail /mnt/net/ipv4/bind/25
+
+  You can grant access to a group for individual ports as well. Just say:
+
+  # chgrp lp /mnt/net/ipv4/bind/515
+  # chown g+x /mnt/net/ipv4/bind/515
+
+  If you're unsure, say N.
+
 #
 # A couple of things I keep forgetting:
 #   capitalize: AppleTalk, Ethernet, DOS, DMA, FAT, FTP, Internet, 
diff -X dontdiff -urN v2.4.14/fs/Config.in linux/fs/Config.in
--- v2.4.14/fs/Config.in	Mon Nov  5 22:40:59 2001
+++ linux/fs/Config.in	Thu Jan 10 19:49:32 2002
@@ -78,6 +78,8 @@
 tristate 'UFS file system support (read only)' CONFIG_UFS_FS
 dep_mbool '  UFS file system write support (DANGEROUS)' CONFIG_UFS_FS_WRITE $CONFIG_UFS_FS $CONFIG_EXPERIMENTAL
 
+dep_bool 'Accessfs support (EXPERIMENTAL)' CONFIG_ACCESS_FS $CONFIG_EXPERIMENTAL
+
 if [ "$CONFIG_NET" = "y" ]; then
 
    mainmenu_option next_comment
diff -X dontdiff -urN v2.4.14/fs/Makefile linux/fs/Makefile
--- v2.4.14/fs/Makefile	Mon Nov  5 22:40:59 2001
+++ linux/fs/Makefile	Thu Jan 10 19:39:46 2002
@@ -64,6 +64,7 @@
 subdir-$(CONFIG_REISERFS_FS)	+= reiserfs
 subdir-$(CONFIG_DEVPTS_FS)	+= devpts
 subdir-$(CONFIG_SUN_OPENPROMFS)	+= openpromfs
+subdir-$(CONFIG_ACCESS_FS)	+= accessfs
 
 
 obj-$(CONFIG_BINFMT_AOUT)	+= binfmt_aout.o
diff -X dontdiff -urN v2.4.14/fs/accessfs/Makefile linux/fs/accessfs/Makefile
--- v2.4.14/fs/accessfs/Makefile	Thu Jan  1 01:00:00 1970
+++ linux/fs/accessfs/Makefile	Thu Jan 10 19:42:52 2002
@@ -0,0 +1,9 @@
+#
+# Makefile for the linux accessfs routines.
+#
+
+O_TARGET := accessfs.o
+obj-y := inode.o
+export-objs := inode.o
+
+include $(TOPDIR)/Rules.make
diff -X dontdiff -urN v2.4.14/fs/accessfs/inode.c linux/fs/accessfs/inode.c
--- v2.4.14/fs/accessfs/inode.c	Thu Jan  1 01:00:00 1970
+++ linux/fs/accessfs/inode.c	Fri Jan 11 22:08:26 2002
@@ -0,0 +1,355 @@
+/* Copyright (c) 2001 Olaf Dietsche
+ *
+ * Access permission filesystem for Linux.
+ */
+
+#include <linux/accessfs_fs.h>
+#include <linux/module.h>
+#include <linux/fs.h>
+#include <linux/pagemap.h>
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/locks.h>
+
+#include <asm/uaccess.h>
+
+typedef struct accessfs_entry	afs_entry_t;
+typedef struct accessfs_direntry	afs_dir_t;
+
+#define ACCESSFS_MAGIC	0x3c1d36e7
+
+static struct inode_operations	accessfs_inode_operations;
+static struct file_operations	accessfs_dir_file_operations;
+static struct inode_operations	accessfs_dir_inode_operations;
+
+static int	accessfs_statfs(struct super_block *sb, struct statfs *buf)
+{
+	buf->f_type = ACCESSFS_MAGIC;
+	buf->f_bsize = PAGE_CACHE_SIZE;
+	buf->f_namelen = 255;
+	return 0;
+}
+
+static int	accessfs_readdir(struct file *filp, void *dirent, filldir_t filldir)
+{
+	int	i;
+	struct dentry	*dentry = filp->f_dentry;
+
+	i = filp->f_pos;
+	switch (i) {
+	case 0:
+		if (filldir(dirent, ".", 1, i, dentry->d_inode->i_ino, DT_DIR) < 0)
+			break;
+
+		++i;
+		++filp->f_pos;
+		/* NO break; */
+	case 1:
+		if (filldir(dirent, "..", 2, i, dentry->d_parent->d_inode->i_ino, DT_DIR) < 0)
+			break;
+
+		++i;
+		++filp->f_pos;
+		/* NO break; */
+	default: {
+		afs_dir_t	*de = (afs_dir_t *) dentry->d_inode->u.generic_ip;
+		struct list_head	*list;
+		int	j;
+
+		list = de->children.next;
+
+		for (j = 2; j < i && list != &de->children; ++j)
+			list = list->next;
+
+		while (list != &de->children) {
+			afs_entry_t	*pe = list_entry(list, afs_entry_t, siblings);
+			if (filldir(dirent, pe->name, strlen(pe->name), filp->f_pos, pe->ino, DT_UNKNOWN) < 0)
+				break;
+
+			++filp->f_pos;
+			list = list->next;
+		}
+	}
+
+		break;
+	}
+
+	return 0;
+}
+
+static afs_entry_t	*accessfs_lookup_entry(afs_entry_t *pe, const char *name, int len)
+{
+	if (S_ISDIR(pe->attr->mode)) {
+		struct list_head	*list;
+		afs_dir_t	*dir = (afs_dir_t *) pe;
+		list_for_each(list, &dir->children) {
+			afs_entry_t	*de = list_entry(list, afs_entry_t, siblings);
+			if (strncmp(de->name, name, len) == 0 && de->name[len] == 0)
+				return de;
+		}
+	}
+
+	return NULL;
+}
+
+static struct dentry	*accessfs_lookup(struct inode *dir, struct dentry *dentry)
+{
+	struct inode	*inode = NULL;
+	afs_entry_t	*pe;
+	pe = accessfs_lookup_entry(dir->u.generic_ip, dentry->d_name.name, dentry->d_name.len);
+	if (pe)
+		inode = iget(dir->i_sb, pe->ino);
+
+	d_add(dentry, inode);
+	return NULL;
+}
+
+static afs_dir_t	accessfs_rootdir = {
+	{ "/", 
+	  LIST_HEAD_INIT(accessfs_rootdir.node.hash), 
+	  LIST_HEAD_INIT(accessfs_rootdir.node.siblings), 
+	  1, &accessfs_rootdir.attr },
+	NULL, LIST_HEAD_INIT(accessfs_rootdir.children), 
+	{ 0, 0, S_IFDIR | 0755 }
+};
+
+static void	accessfs_init_inode(struct inode *inode, afs_entry_t *pe)
+{
+	inode->u.generic_ip = pe;
+	inode->i_uid = pe->attr->uid;
+	inode->i_gid = pe->attr->gid;
+	inode->i_mode = pe->attr->mode;
+/*
+	inode->i_blksize = PAGE_CACHE_SIZE;
+	inode->i_blocks = 0;
+	inode->i_rdev = NODEV;
+*/
+	inode->i_atime = inode->i_mtime = inode->i_ctime = 0;
+	switch (inode->i_mode & S_IFMT) {
+	case S_IFREG:
+		inode->i_op = &accessfs_inode_operations;
+		break;
+	case S_IFDIR:
+		inode->i_op = &accessfs_dir_inode_operations;
+		inode->i_fop = &accessfs_dir_file_operations;
+		break;
+	default:
+		printk(KERN_ERR "accessfs_init_inode(): '%s' unhandled mode=%d\n", pe->name, inode->i_mode);
+		BUG();
+		break;
+	}
+}
+
+static struct inode	*accessfs_get_root_inode(struct super_block *sb)
+{
+	struct inode	*inode = new_inode(sb);
+	if (inode) {
+/* 		inode->i_ino = accessfs_rootdir.node.ino; */
+		accessfs_init_inode(inode, &accessfs_rootdir.node);
+		accessfs_rootdir.node.ino = inode->i_ino;
+	}
+
+	return inode;
+}
+
+static LIST_HEAD(hash);
+
+static int	accessfs_node_init(afs_dir_t *parent, afs_entry_t *de, const char *name, size_t len, struct access_attr *attr, mode_t mode)
+{
+	static unsigned long	ino = 1;
+	de->name = kmalloc(len + 1, GFP_KERNEL);
+	if (de->name == NULL)
+		return -ENOMEM;
+
+	strncpy(de->name, name, len);
+	de->name[len] = 0;
+	de->ino = ++ino;
+	de->attr = attr;
+	de->attr->uid = 0;
+	de->attr->gid = 0;
+	de->attr->mode = mode;
+	list_add_tail(&de->hash, &hash);
+	list_add_tail(&de->siblings, &parent->children);
+	return 0;
+}
+
+static int	accessfs_mknod(afs_dir_t *dir, const char *name, struct access_attr *attr)
+{
+	afs_entry_t	*pe = kmalloc(sizeof(afs_entry_t), GFP_KERNEL);
+	if (pe == NULL)
+		return -ENOMEM;
+
+	accessfs_node_init(dir, pe, name, strlen(name), attr, S_IFREG | attr->mode);
+	return 0;
+}
+
+static afs_dir_t	*accessfs_mkdir(afs_dir_t *parent, const char *name, size_t len)
+{
+	int	error;
+	afs_dir_t	*dir = kmalloc(sizeof(afs_dir_t), GFP_KERNEL);
+	if (dir == NULL)
+		return NULL;
+
+	error = accessfs_node_init(parent, &dir->node, name, len, &dir->attr, S_IFDIR | 0755);
+	if (error) {
+		kfree(dir);
+		return NULL;
+	}
+
+	dir->parent = parent;
+	INIT_LIST_HEAD(&dir->children);
+	return dir;
+}
+
+afs_dir_t	*accessfs_make_dirpath(const char *name)
+{
+	afs_dir_t	*dir = &accessfs_rootdir;
+	const char	*slash;
+	do {
+		afs_entry_t	*de;
+		size_t	len;
+		while (*name == '/')
+			++name;
+
+		slash = strchr(name, '/');
+		len = slash ? slash - name : strlen(name);
+		de = accessfs_lookup_entry(&dir->node, name, len);
+		if (de == NULL) {
+			dir = accessfs_mkdir(dir, name, len);
+		} else if (S_ISDIR(de->attr->mode)) {
+			dir = (afs_dir_t *) de;
+		} else {
+			return NULL;
+		}
+
+		if (dir == NULL)
+			return NULL;
+
+		name = slash  + 1;
+	} while (slash != NULL);
+
+	return dir;
+}
+
+static void	accessfs_unlink(afs_entry_t *pe)
+{
+	list_del(&pe->hash);
+	list_del(&pe->siblings);
+	kfree(pe->name);
+	kfree(pe);
+}
+
+static int	accessfs_notify_change(struct dentry *dentry, struct iattr *iattr)
+{
+	struct inode	*i = dentry->d_inode;
+	int	error = inode_setattr(i, iattr);
+	if (!error) {
+		afs_entry_t	*pe = (afs_entry_t *) i->u.generic_ip;
+		pe->attr->uid = i->i_uid;
+		pe->attr->gid = i->i_gid;
+		pe->attr->mode = i->i_mode;
+	}
+
+	return error;
+}
+
+static void	accessfs_read_inode(struct inode *inode)
+{
+	ino_t	ino = inode->i_ino;
+	struct list_head	*list;
+	list_for_each(list, &hash) {
+		afs_entry_t	*pe = list_entry(list, afs_entry_t, hash);
+		if (pe->ino == ino) {
+			accessfs_init_inode(inode, pe);
+			return;
+		}
+	}
+}
+
+static struct inode_operations	accessfs_inode_operations = {
+	setattr:	accessfs_notify_change,
+};
+
+static struct inode_operations	accessfs_dir_inode_operations = {
+	lookup:	accessfs_lookup,
+	setattr:	accessfs_notify_change,
+};
+
+static struct file_operations	accessfs_dir_file_operations = {
+	readdir:	accessfs_readdir,
+};
+
+static struct super_operations	accessfs_ops = {
+	read_inode:	accessfs_read_inode,
+	statfs:		accessfs_statfs,
+};
+
+static struct super_block	*accessfs_read_super(struct super_block *sb, void *data, int silent)
+{
+	struct inode	*inode;
+	struct dentry	*root;
+
+	sb->s_blocksize = PAGE_CACHE_SIZE;
+	sb->s_blocksize_bits = PAGE_CACHE_SHIFT;
+	sb->s_magic = ACCESSFS_MAGIC;
+	sb->s_op = &accessfs_ops;
+	inode = accessfs_get_root_inode(sb);
+	if (!inode)
+		return NULL;
+
+	root = d_alloc_root(inode);
+	if (!root) {
+		iput(inode);
+		return NULL;
+	}
+
+	sb->s_root = root;
+	return sb;
+}
+
+int	accessfs_permitted(struct access_attr *p, int mask)
+{
+	mode_t	mode = p->mode;
+	if (current->fsuid == p->uid)
+		mode >>= 6;
+	else if (in_group_p(p->gid))
+		mode >>= 3;
+
+	return (mode & mask) == mask;
+}
+
+void	accessfs_register(afs_dir_t *dir, const char *name, struct access_attr *attr)
+{
+	if (dir) {
+		accessfs_mknod(dir, name, attr);
+	}
+}
+
+void	accessfs_unregister(afs_dir_t *dir, const char *name)
+{
+	afs_entry_t	*pe = accessfs_lookup_entry(&dir->node, name, strlen(name));
+	if (pe) {
+		accessfs_unlink(pe);
+	}
+}
+
+static DECLARE_FSTYPE(accessfs_fs_type, "accessfs", accessfs_read_super, FS_SINGLE);
+
+static int __init init_accessfs_fs(void)
+{
+	return register_filesystem(&accessfs_fs_type);
+}
+
+static void __exit exit_accessfs_fs(void)
+{
+	unregister_filesystem(&accessfs_fs_type);
+}
+
+module_init(init_accessfs_fs)
+module_exit(exit_accessfs_fs)
+
+EXPORT_SYMBOL(accessfs_permitted);
+EXPORT_SYMBOL(accessfs_make_dirpath);
+EXPORT_SYMBOL(accessfs_register);
+EXPORT_SYMBOL(accessfs_unregister);
diff -X dontdiff -urN v2.4.14/include/linux/accessfs_fs.h linux/include/linux/accessfs_fs.h
--- v2.4.14/include/linux/accessfs_fs.h	Thu Jan  1 01:00:00 1970
+++ linux/include/linux/accessfs_fs.h	Fri Jan 11 22:10:18 2002
@@ -0,0 +1,38 @@
+/* -*- mode: c -*- */
+#ifndef	__accessfs_fs_h_included__
+#define	__accessfs_fs_h_included__	1
+
+/* Copyright (c) 2001 Olaf Dietsche
+ *
+ * $Log$
+ */
+
+#include	<linux/fs.h>
+
+struct access_attr {
+	uid_t	uid;
+	gid_t	gid;
+	mode_t	mode;
+};
+
+struct accessfs_entry {
+	char	*name;
+	struct list_head	hash;
+	struct list_head	siblings;
+	ino_t	ino;
+	struct access_attr	*attr;
+};
+
+struct accessfs_direntry {
+	struct accessfs_entry	node;
+	struct accessfs_direntry	*parent;
+	struct list_head	children;
+	struct access_attr	attr;
+};
+
+extern int	accessfs_permitted(struct access_attr *p, int mask);
+extern struct accessfs_direntry	*accessfs_make_dirpath(const char *name);
+extern void	accessfs_register(struct accessfs_direntry *dir, const char *name, struct access_attr *attr);
+extern void	accessfs_unregister(struct accessfs_direntry *dir, const char *name);
+
+#endif
diff -X dontdiff -urN v2.4.14/net/ipv4/af_inet.c linux/net/ipv4/af_inet.c
--- v2.4.14/net/ipv4/af_inet.c	Mon Nov  5 18:46:12 2001
+++ linux/net/ipv4/af_inet.c	Thu Jan 10 20:14:29 2002
@@ -116,6 +116,9 @@
 #if defined(CONFIG_NET_RADIO) || defined(CONFIG_NET_PCMCIA_RADIO)
 #include <linux/wireless.h>		/* Note : will define WIRELESS_EXT */
 #endif	/* CONFIG_NET_RADIO || CONFIG_NET_PCMCIA_RADIO */
+#ifdef CONFIG_ACCESS_FS
+#include <linux/accessfs_fs.h>
+#endif
 
 struct linux_mib net_statistics[NR_CPUS*2];
 
@@ -467,6 +470,10 @@
 	return(0);
 }
 
+#ifdef CONFIG_ACCESS_FS
+static struct access_attr bind_to_port[PROT_SOCK];
+#endif
+
 /* It is off by default, see below. */
 int sysctl_ip_nonlocal_bind;
 
@@ -503,7 +510,11 @@
 		return -EADDRNOTAVAIL;
 
 	snum = ntohs(addr->sin_port);
+#ifdef CONFIG_ACCESS_FS
+	if (snum && snum < PROT_SOCK && !accessfs_permitted(&bind_to_port[snum], MAY_EXEC))
+#else
 	if (snum && snum < PROT_SOCK && !capable(CAP_NET_BIND_SERVICE))
+#endif
 		return -EACCES;
 
 	/*      We keep a pair of addresses. rcv_saddr is the one
@@ -1101,6 +1112,21 @@
 	}
 }
 
+#ifdef CONFIG_ACCESS_FS
+static void	accessfs_init(void)
+{
+	struct accessfs_direntry *dir = accessfs_make_dirpath("net/ipv4/bind");
+	int i;
+	for (i = 1; i < PROT_SOCK; ++i) {
+		char	buf[sizeof("1023")];
+		bind_to_port[i].uid = 0;
+		bind_to_port[i].gid = 0;
+		bind_to_port[i].mode = S_IXUSR;
+		sprintf(buf, "%d", i);
+		accessfs_register(dir, buf, &bind_to_port[i]);
+	}
+}
+#endif
 
 /*
  *	Called by socket.c on kernel startup.  
@@ -1197,6 +1223,11 @@
 	proc_net_create ("tcp", 0, tcp_get_info);
 	proc_net_create ("udp", 0, udp_get_info);
 #endif		/* CONFIG_PROC_FS */
+
+#ifdef CONFIG_ACCESS_FS
+	accessfs_init();
+#endif
+
 	return 0;
 }
 module_init(inet_init);

Re: [ANNOUNCE][PATCH] New fs to control access to system resources

[Richard Gooch]

Olaf Dietsche writes:
> --=-=-=
> 
> Hi,
> 
> this is a new file system to control access to system resources.
> Currently it controls access to inet_bind() with ports < 1024 only.
> 
> With this patch, there's no need anymore to run internet daemons as
> root. You can individually configure which user/program can bind to
> ports below 1024.
> 
> For example, you can say, user www is allowed to bind to port 80 or
> user mail is allowed to bind to port 25. Then, you can run apache as
> user www and sendmail as user mail. Now, you don't have to rely on
> apache or sendmail giving up superuser rights to enhance security.
> 
> To use this, you need to mount the file system and do a chown on the
> appropriate ports:
> 
> # mount -t accessfs none /mnt
> # chown www /mnt/net/ipv4/bind/80
> # chown mail /mnt/net/ipv4/bind/25

Having to set the permissions like this on each boot seems a bit
painful. Why not have permissions persistence like devfs has?

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [ANNOUNCE][PATCH] New fs to control access to system resources

[Wichert Akkerman]

In article <200201151653.g0FGrlG12428@vindaloo.ras.ucalgary.ca>,
Richard Gooch  <rgooch@ras.ucalgary.ca> wrote:
>Having to set the permissions like this on each boot seems a bit
>painful. Why not have permissions persistence like devfs has?

Maybe you could abstract that persistency from devfs and move
it into a general layer that other filesytems can also use.

Wichert.

-- 
  _________________________________________________________________
 /       Nothing is fool-proof to a sufficiently talented fool     \
| wichert@wiggy.net                   http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: [ANNOUNCE][PATCH] New fs to control access to system resources

[Richard Gooch]

Wichert Akkerman writes:
> In article <200201151653.g0FGrlG12428@vindaloo.ras.ucalgary.ca>,
> Richard Gooch  <rgooch@ras.ucalgary.ca> wrote:
> >Having to set the permissions like this on each boot seems a bit
> >painful. Why not have permissions persistence like devfs has?
> 
> Maybe you could abstract that persistency from devfs and move
> it into a general layer that other filesytems can also use.

I suggested that last week in another thread (about Yet Another
Virtual FS), and heard a deafening silence. I'm not sure if it's
easier to provide a general layer, or to just make things available
via devfs. Having a general layer implies multiple persistence daemons
(aka devfsd), one for each virtual FS with persistence.

I was hoping to start some discussion about this, but it seems people
care more about Aunt Tilly :-)

I'm sure some people will scream at the top of their lungs against the
idea of making other information available via devfs, but maybe some
of those screams will be muffled once I release v2.0 of the devfs core
(that's the one where the internal tree is ripped out and the dcache
is used instead: should be a big code reduction). At least with v1.9
of the devfs core all known races have been removed, so hopefully that
softens the resistance :-)

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [ANNOUNCE][PATCH] New fs to control access to system resources

[Olaf Dietsche]

Hi,

Richard Gooch <rgooch@ras.ucalgary.ca> writes:

> Olaf Dietsche writes:
> > To use this, you need to mount the file system and do a chown on the
> > appropriate ports:
> > 
> > # mount -t accessfs none /mnt
> > # chown www /mnt/net/ipv4/bind/80
> > # chown mail /mnt/net/ipv4/bind/25
> 
> Having to set the permissions like this on each boot seems a bit
> painful. Why not have permissions persistence like devfs has?

Well, for me it's a small script running at boot time. So, there's no
pain at all, unless planning or thinking in advance qualifies as pain ;-).

Seriously, this is a first cut. If there is real demand, I'll try to
come up with something. But I think, this will be a job for system
administrators or distribution builders. So, maybe a shell script with
fixed permissions will be sufficient. We will see.

First of all, I want to see, wether people like it at all or come up
alternative ideas.

Regards, Olaf.

Re: [ANNOUNCE][PATCH] New fs to control access to system resources

[Andreas Ferber]

On Tue, Jan 15, 2002 at 09:53:47AM -0700, Richard Gooch wrote:
> 
> Having to set the permissions like this on each boot seems a bit
> painful. Why not have permissions persistence like devfs has?

At least for the moment I don't think this is necessary.

Keep in mind that accessfs with the current ressource coverage
contains only entries which are static after initialization (except
for user-initiated permission changes of course), not like devfs where
entries are appearing, disappearing and reappearing all the time when
modules are loaded/unloaded etc. So a small shell script which sets
permissions once after boot should suffice in all cases (one could
also write a script which saves permissions on shutdown, to
automatically preserve changes made by the admin). 

Andreas
-- 
       Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
     ---------------------------------------------------------
         +49 521 1365800 - af@devcon.net - www.devcon.net

Re: [ANNOUNCE][PATCH] New fs to control access to system resources

[Ben Clifford]

Olaf,

After applying your patch to 2.5.2, my named wouldn't start up (it
couldn't bind to port 921)

The below patch seems to have fixed that, and I think is probably the
right thing to do.

Index: net/ipv4/af_inet.c
===================================================================
RCS file: /mnt/white/cvsroot/linux/net/ipv4/af_inet.c,v
retrieving revision 1.2
diff -u -r1.2 af_inet.c
--- net/ipv4/af_inet.c	2002/01/15 21:20:02	1.2
+++ net/ipv4/af_inet.c	2002/01/15 22:04:00
@@ -511,7 +511,7 @@

 	snum = ntohs(addr->sin_port);
 #ifdef CONFIG_ACCESS_FS
-	if (snum && snum < PROT_SOCK && !accessfs_permitted(&bind_to_port[snum], MAY_EXEC))
+	if (snum && snum < PROT_SOCK && !accessfs_permitted(&bind_to_port[snum], MAY_EXEC) && !capable(CAP_NET_BIND_SERVICE))
 #else
 	if (snum && snum < PROT_SOCK && !capable(CAP_NET_BIND_SERVICE))
 #endif

Measuring execution time

[Mark Cuss]

Hello all,

I'm not sure if this is the place to ask this particular question - if not,
my apologies ....

I am working on optimizing some software and would like to be able to
measure how long an instruction takes (down to the clock cycle of the CPU).
I recall reading somewhere about a kernel time measurement called a "Jiffy"
and figured that it would probably apply to this.

If anyone has any tips on how to figure out how to do this I'd really
appreciate it.

Thanks!

Mark

Re: Measuring execution time

[Chris Friesen]

Mark Cuss wrote:

> I am working on optimizing some software and would like to be able to
> measure how long an instruction takes (down to the clock cycle of the CPU).
> I recall reading somewhere about a kernel time measurement called a "Jiffy"
> and figured that it would probably apply to this.
> 
> If anyone has any tips on how to figure out how to do this I'd really
> appreciate it.

Jiffies are quite coarse-grained.  On x86 you want the rdtsc instruction, while
on ppc you want mfrtcu/mfrtcl or mftbu/mftb depending on the version of the
chip.  These are used as inline assembly, and if you do a google search you
should be able to find code snippets.

Chris

-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: Measuring execution time

[Richard B. Johnson]

On Wed, 16 Jan 2002, Chris Friesen wrote:

> Mark Cuss wrote:
> 
> > I am working on optimizing some software and would like to be able to
> > measure how long an instruction takes (down to the clock cycle of the CPU).
> > I recall reading somewhere about a kernel time measurement called a "Jiffy"
> > and figured that it would probably apply to this.
> > 
> > If anyone has any tips on how to figure out how to do this I'd really
> > appreciate it.
> 
> Jiffies are quite coarse-grained.  On x86 you want the rdtsc instruction, while
> on ppc you want mfrtcu/mfrtcl or mftbu/mftb depending on the version of the
> chip.  These are used as inline assembly, and if you do a google search you
> should be able to find code snippets.
> 

For Intel.......

Assemble this as rdtsc.S

.data
lastl:	.long	0
lasth:	.long	0
.text
.align	8	
.globl	tim
.type 	tim@function

#
#  Return the CPU clock difference between successive calls.
#
tim:	pushl	%ebx
	rdtsc
	movl	lastl, %ebx		# Get last low longword
	movl	lasth, %ecx		# Get last high longword
	movl	%eax, lastl		# Save current low longword
	movl	%edx, lasth		# Save current high longword
	subl	%ebx, %eax		# Current - last
	sbbl	%ecx, %edx		# Same with borrow
	popl	%ebx
	ret
.end


Your code:

/* Really extern long long tim(void); */
extern long tim(void); /* Good enough */

main()
{
    long total_cycles;

    (void)tim();      /* Grab starting time */
    process();        /* Do your code */
    total_cycles = tim();

}

gcc -o tester main.c rdtsc.S



Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: Measuring execution time

[Jakob Østergaard]

On Wed, Jan 16, 2002 at 12:23:33PM -0500, Chris Friesen wrote:
> Mark Cuss wrote:
> 
> > I am working on optimizing some software and would like to be able to
> > measure how long an instruction takes (down to the clock cycle of the CPU).
> > I recall reading somewhere about a kernel time measurement called a "Jiffy"
> > and figured that it would probably apply to this.
> > 
> > If anyone has any tips on how to figure out how to do this I'd really
> > appreciate it.
> 
> Jiffies are quite coarse-grained.  On x86 you want the rdtsc instruction, while
> on ppc you want mfrtcu/mfrtcl or mftbu/mftb depending on the version of the
> chip.  These are used as inline assembly, and if you do a google search you
> should be able to find code snippets.

However,  rdtsc will completely change how your decoders fill, how busy your
execution units are, it will interfere with every singe stage in the CPU
from the fetch logic to the retirement and write buffer.

Your cycle will not behave "as usual" if you put rdtscs around it.

I usually put an rdtsc in the very beginning of a routine, and an rdtsc
at the end.  Then I have the assembly following the last rdtsc increment
a counter in an array (after a bounds check).  The index in the array
is the number of clock cycles I spent.

After running the function some thousands of times, you will have a nice
histogram in your array, usually with some skewed bell-like curve (you can
see many interesting kinds of double/triple bells etc. all depending on
your code).

Changing just one or two instructions in the function, then re-running the
code and re-plotting the histogram, will displace the peak of the bell curve
in some direction.  This will tell you how your change affected the code
in "typical number of clock cycles".

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

Re: [ANNOUNCE][PATCH] New fs to control access to system resources

[Olaf Dietsche]

Hi Ben,

I just managed to build and boot 2.5.2 plus my patch. My named starts
without any problem. So, sorry can't reproduce it here.

Ben Clifford <benc@hawaga.org.uk> writes:

> After applying your patch to 2.5.2, my named wouldn't start up (it
> couldn't bind to port 921)

This sounds weird. Normally, named binds to port 53 and some high
unprivileged port for replies from other DNS servers. Do you have some
'listen-on' and/or 'query-source' statements in your named.conf? If
you do, just change permissions of /mnt/net/ipv4/bind/921 appropriately.

> The below patch seems to have fixed that, and I think is probably the
> right thing to do.
[...]
> -	if (snum && snum < PROT_SOCK && !accessfs_permitted(&bind_to_port[snum], MAY_EXEC))
> +	if (snum && snum < PROT_SOCK && !accessfs_permitted(&bind_to_port[snum], MAY_EXEC) && !capable(CAP_NET_BIND_SERVICE))

You may use accessfs and capabilities in parallel, of course. But
currently, this is equivalent to "chown root/chmod u+x".

Regards, Olaf.

Re: [ANNOUNCE][PATCH] New fs to control access to system resources

[Ben Clifford]

On 16 Jan 2002, Olaf Dietsche wrote:

> This sounds weird. Normally, named binds to port 53 and some high
> unprivileged port for replies from other DNS servers. Do you have some
> 'listen-on' and/or 'query-source' statements in your named.conf? If
> you do, just change permissions of /mnt/net/ipv4/bind/921 appropriately.

The port 53 bindings happen without problem.

BINDv9 has a lightweight resolver service which runs on port 921 - this is
not enabled by default, and when it is enabled, seems to start up later on
in the startup process.


Add the single line:
lwres {};
in your named.conf and it will be enabled.



> You may use accessfs and capabilities in parallel, of course. But
> currently, this is equivalent to "chown root/chmod u+x".

Taking capabilities away seems to break backwards compatibility.

And I'm not entirely sure it *is* equivalent to chown root/chmod u+x -
that is how /mnt/accessfs/net/ipv4/bind appeared and my named couldn't
bind to 921.

Ben

-- 
Ben Clifford     benc@hawaga.org.uk     GPG: 30F06950
Job Required in Los Angeles - Will do most things unix or IP for money.
http://www.hawaga.org.uk/resume/resume001.pdf

Re: [ANNOUNCE][PATCH] New fs to control access to system resources

[Olaf Dietsche]

Ben Clifford <benc@hawaga.org.uk> writes:

> The port 53 bindings happen without problem.
> 
> BINDv9 has a lightweight resolver service which runs on port 921 - this is
> not enabled by default, and when it is enabled, seems to start up later on
> in the startup process.

Ok, I'm running BINDv8 right now.

> > You may use accessfs and capabilities in parallel, of course. But
> > currently, this is equivalent to "chown root/chmod u+x".
> 
> Taking capabilities away seems to break backwards compatibility.

I'll think about this. I haven't heard about a working system or tools,
which use capabilities yet. So I thought, nobody would see a difference.

> And I'm not entirely sure it *is* equivalent to chown root/chmod u+x -
> that is how /mnt/accessfs/net/ipv4/bind appeared and my named couldn't
> bind to 921.

I will investigate this further. Seems, I need to install BINDv9 to
reproduce this problem.

Regards, Olaf.

Re: [ANNOUNCE][PATCH] New fs to control access to system resources

[CaT]

On Tue, Jan 15, 2002 at 05:01:11PM +0100, Olaf Dietsche wrote:
> Hi,
> 
> this is a new file system to control access to system resources.
> Currently it controls access to inet_bind() with ports < 1024 only.

Woo. :) I've been thinking of making something like this my first
kernel project but you beat me to it. Drat. :)

-- 
SOCCER PLAYER IN GENITAL-BITING SCANDAL  ---  "It was something between
friends that I thought would have no importance until this morning when
I got up and saw all  the commotion in the news,"  Gallardo told a news
conference. "It stunned me."
Reyes told Marca that he had "felt a slight pinch."

Re: [ANNOUNCE][PATCH] New fs to control access to system resources

[David Weinehall]

On Wed, Jan 16, 2002 at 09:51:40AM +1100, CaT wrote:
> On Tue, Jan 15, 2002 at 05:01:11PM +0100, Olaf Dietsche wrote:
> > Hi,
> > 
> > this is a new file system to control access to system resources.
> > Currently it controls access to inet_bind() with ports < 1024 only.
> 
> Woo. :) I've been thinking of making something like this my first
> kernel project but you beat me to it. Drat. :)

I guess it's time to revise the old Unix saying "everything is a file"
to "everything is a file system" =)


Regards: David Weinehall
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: [ANNOUNCE][PATCH] New fs to control access to system resources

[CaT]

On Wed, Jan 16, 2002 at 12:00:57AM +0100, David Weinehall wrote:
> On Wed, Jan 16, 2002 at 09:51:40AM +1100, CaT wrote:
> > On Tue, Jan 15, 2002 at 05:01:11PM +0100, Olaf Dietsche wrote:
> > > Hi,
> > > 
> > > this is a new file system to control access to system resources.
> > > Currently it controls access to inet_bind() with ports < 1024 only.
> > 
> > Woo. :) I've been thinking of making something like this my first
> > kernel project but you beat me to it. Drat. :)
> 
> I guess it's time to revise the old Unix saying "everything is a file"
> to "everything is a file system" =)

Well it is on a mac (more or less). Resource forks are a mini
filesystem. :)

-- 
SOCCER PLAYER IN GENITAL-BITING SCANDAL  ---  "It was something between
friends that I thought would have no importance until this morning when
I got up and saw all  the commotion in the news,"  Gallardo told a news
conference. "It stunned me."
Reyes told Marca that he had "felt a slight pinch."

Re: [ANNOUNCE][PATCH] New fs to control access to system resources

[dean gaudet]

On 15 Jan 2002, Olaf Dietsche wrote:

> For example, you can say, user www is allowed to bind to port 80 or
> user mail is allowed to bind to port 25. Then, you can run apache as
> user www and sendmail as user mail. Now, you don't have to rely on
> apache or sendmail giving up superuser rights to enhance security.

typically logging must also occur as some other user than what the daemon
runs as, or else your logs are suspect in any sort of break-in.  this is
no problem for stuff using syslog, but since that's not the default
configuration for apache you might want to put a note in any docs you end
up including.  one suggestion is piped logging through a setuid logger
(setuid to user wwwlogs or something, root not required).

-dean

Re: [ANNOUNCE][PATCH] New fs to control access to system resources

[Olaf Dietsche]

dean gaudet <dean-list-linux-kernel@arctic.org> writes:

> On 15 Jan 2002, Olaf Dietsche wrote:
> 
> > For example, you can say, user www is allowed to bind to port 80 or
> > user mail is allowed to bind to port 25. Then, you can run apache as
> > user www and sendmail as user mail. Now, you don't have to rely on
> > apache or sendmail giving up superuser rights to enhance security.
> 
> typically logging must also occur as some other user than what the daemon
> runs as, or else your logs are suspect in any sort of break-in.  this is
> no problem for stuff using syslog, but since that's not the default
> configuration for apache you might want to put a note in any docs you end
> up including.  one suggestion is piped logging through a setuid logger
> (setuid to user wwwlogs or something, root not required).

Right. But that's user space and shouldn't impact the kernel/accessfs.
Or did I miss something?

Regards, Olaf.

Re: [ANNOUNCE][PATCH] New fs to control access to system resources

[dean gaudet]

On 16 Jan 2002, Olaf Dietsche wrote:

> dean gaudet <dean-list-linux-kernel@arctic.org> writes:
>
> > On 15 Jan 2002, Olaf Dietsche wrote:
> >
> > > For example, you can say, user www is allowed to bind to port 80 or
> > > user mail is allowed to bind to port 25. Then, you can run apache as
> > > user www and sendmail as user mail. Now, you don't have to rely on
> > > apache or sendmail giving up superuser rights to enhance security.
> >
> > typically logging must also occur as some other user than what the daemon
> > runs as, or else your logs are suspect in any sort of break-in.  this is
> > no problem for stuff using syslog, but since that's not the default
> > configuration for apache you might want to put a note in any docs you end
> > up including.  one suggestion is piped logging through a setuid logger
> > (setuid to user wwwlogs or something, root not required).
>
> Right. But that's user space and shouldn't impact the kernel/accessfs.
> Or did I miss something?

no kernel impact ... i was just suggesting that any accompanying
documentation should be careful to imply that the one change to allow www
to open 80 is all that's required to get rid of apache's root privs.  i'm
just worried folks will blindly chown their logs to www.

-dean

Re: [ANNOUNCE][PATCH] New fs to control access to system resources

[Olaf Dietsche]

dean gaudet <dean-list-linux-kernel@arctic.org> writes:

> no kernel impact ... i was just suggesting that any accompanying
> documentation should be careful to imply that the one change to allow www
> to open 80 is all that's required to get rid of apache's root privs.  i'm
> just worried folks will blindly chown their logs to www.

Ok, now I understand your suggestion. Seems, I have to learn a lot
more about security. Thanks, I will think about this issue.

Regards, Olaf.

Re: [ANNOUNCE][PATCH] New fs to control access to system resources

[Andreas Ferber]

On Tue, Jan 15, 2002 at 05:01:11PM +0100, Olaf Dietsche wrote:
> 
> this is a new file system to control access to system resources.
> Currently it controls access to inet_bind() with ports < 1024 only.

Just some minor notes from reading the source and docs:

- It somewhat collides with the Linux Security Module project
  (http://lsm.immunix.org/). LSM is AFAIK very likely to be included
  into kernel somewhere in the 2.5 timeframe, so I don't think your
  accessfs in its current form will be included into 2.5. Also I don't
  think it will be included into 2.4 some time, as it is rather
  intrusive. This doesn't mean that I think your work is bogus, but
  you should be warned that you will most likely have to maintain it
  as a separate patch at least until you port it to LSM (which
  probably will not be possible at least in the first phase of LSM -
  read the discussions on "restrictive vs. authoritative hooks" in the
  LSM mailinglist archives).
- CAP_NET_BIND_SERVICE is ignored completely. IMHO a process with this
  capability should still be able to override the accessfs
  permissions, otherwise enabling accessfs will break every setup
  where CAP_NET_BIND_SERVICE is already used to give non-root
  processes access to low ports. At least this should be mentioned in
  the docs (and Configure.help entry!), as it means that you can't mix
  the accessfs and the capability approach on a machine (e.g. if one
  wants to migrate the services on the machine one for one). It also
  breaks any network daemons that already use CAP_NET_BIND_SERVICE
  internally (don't know of an example, but maybe there are some out
  there).
- chown()ing a port to a uid provides this uid also with the ability
  to pass on access privileges to others via chmod(). It could be
  argued if it is more sensible to restrict changing privileges to
  root (maybe CAP_NET_ADMIN is more appropriate?).

And some wishlist items:

- It would be nice if there were a way to distinguish between TCP and
  UDP ports.
- IPv6 support would be nice. This raises the question what will
  happen if a process has the privileges to bind a particular port
  with IPv6 but not with IPv4 (IPv6 listeners take IPv4 connections
  also). Is there any value in distinguishing IPv6 and IPv4 at all,
  in particular if IPv6 gets into more widespread use in the future?
- Restricting access to certain high ports would be valuable. For
  example many SQL server use those ports, and it would be nice if one
  could prevent ordinary user processes from taking over their ports
  in case the SQL daemon gets restarted or the like.

At least accessfs is a nice and expandable idea. Keep up the work :-)

Andreas
-- 
       Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
     ---------------------------------------------------------
         +49 521 1365800 - af@devcon.net - www.devcon.net

Re: [ANNOUNCE][PATCH] New fs to control access to system resources

[gmack]

On Wed, 16 Jan 2002, Andreas Ferber wrote:

> And some wishlist items:
> 
> - It would be nice if there were a way to distinguish between TCP and
>   UDP ports.
> - IPv6 support would be nice. This raises the question what will
>   happen if a process has the privileges to bind a particular port
>   with IPv6 but not with IPv4 (IPv6 listeners take IPv4 connections
>   also). Is there any value in distinguishing IPv6 and IPv4 at all,
>   in particular if IPv6 gets into more widespread use in the future?
> - Restricting access to certain high ports would be valuable. For
>   example many SQL server use those ports, and it would be nice if one
>   could prevent ordinary user processes from taking over their ports
>   in case the SQL daemon gets restarted or the like.
> 
> At least accessfs is a nice and expandable idea. Keep up the work :-)
> 

What would be nice would be to have a way to restrict access to ports
based on IP ex: user1 gets 10.0.0.1 and user2 gets 10.0.0.2.

	Gerhard

--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

Re: [ANNOUNCE][PATCH] New fs to control access to system resources

[Greg KH]

On Wed, Jan 16, 2002 at 07:51:06PM +0100, Andreas Ferber wrote:
> On Tue, Jan 15, 2002 at 05:01:11PM +0100, Olaf Dietsche wrote:
> > 
> > this is a new file system to control access to system resources.
> > Currently it controls access to inet_bind() with ports < 1024 only.
> 
> Just some minor notes from reading the source and docs:
> 
> - It somewhat collides with the Linux Security Module project
>   (http://lsm.immunix.org/).

I don't see this conflicting with what the lsm patch does (with the
minor exception of removing the capable() call.)  How do you see a
conflict here?

This patch looks nice, I like it.

Yet another reason why we should have a bunch of the ramfs functions
exported for the rest of the kernel to use :)

thanks,

greg k-h

Re: [ANNOUNCE][PATCH] New fs to control access to system resources

[Andreas Ferber]

On Wed, Jan 16, 2002 at 03:06:21PM -0800, Greg KH wrote:
> > 
> > - It somewhat collides with the Linux Security Module project
> >   (http://lsm.immunix.org/).
> I don't see this conflicting with what the lsm patch does (with the
> minor exception of removing the capable() call.)  How do you see a
> conflict here?

I don't mean a conflict in the implementation. Clearly it is possible
to combine accessfs checks with LSM hooks (indeed, I think this is
the only possible way for accessfs until LSM gets authoritative
hooks - hey, this could be an example project for "authoritative"
advocates :-).

My concern was conceptual: accessfs is just another mechanism for
access control to various ressources. As I understand it, LSM is
intended to move /all/ access control logic into separate modules with
a uniform interface to the kernel, so that you can choose whatever
access control mechanism you want (or even rip out all access control,
as for example some embedded applications don't need it). Clearly it's
a long way until LSM actually gets to this point, but nevertheless
it's the overall goal of the whole effort IMHO.

Moving accessfs to use LSM hooks means only changes at the
implementation level, no changes of the concept or user interface of
accessfs are needed. What I wanted to express was only that the LSM
effort may put some constraints on the timeline for kernel inclusion
of accessfs ("collide" vs. "conflict" ;-).

> This patch looks nice, I like it.

I totally agree with that. Maybe I should have expressed it more
clearly in my first mail ;-)

Andreas
-- 
       Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
     ---------------------------------------------------------
         +49 521 1365800 - af@devcon.net - www.devcon.net

Re: [ANNOUNCE][PATCH] New fs to control access to system resources

[Greg KH]

On Thu, Jan 17, 2002 at 10:26:51AM +0100, Andreas Ferber wrote:
> 
> My concern was conceptual: accessfs is just another mechanism for
> access control to various ressources. As I understand it, LSM is
> intended to move /all/ access control logic into separate modules with
> a uniform interface to the kernel, so that you can choose whatever
> access control mechanism you want (or even rip out all access control,
> as for example some embedded applications don't need it). Clearly it's
> a long way until LSM actually gets to this point, but nevertheless
> it's the overall goal of the whole effort IMHO.

The LSM patch's goal is to only _allow_ you do add access control
mechanisms to the kernel easily.

This accessfs patch doesn't collide with that goal at all.  If it gets
accepted into the kernel, people who write LSM based access control
modules need to remember to medaite access to the accessfs if they want
to.  Since the LSM hooks are much lower in the vfs than accessfs, it is
a simple thing to add this kind of access mediation.

Hope this helps clear it up a bit.

thanks,

greg k-h

Re: [ANNOUNCE][PATCH] New fs to control access to system resources

[Anthony DeRobertis]

This idea seems to be popular:

http://www.google.com/search?q=sockfs

I must say I like the idea myself.

Re: [ANNOUNCE][PATCH] New fs to control access to system resources

[Olaf Dietsche]

Anthony DeRobertis <asd@suespammers.org> writes:

> This idea seems to be popular:

Well, it's a good idea :-).

> http://www.google.com/search?q=sockfs

Thanks for the pointer.

Regards, Olaf.