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: [email protected]
Current: [email protected]
In article <[email protected]>,
Richard Gooch <[email protected]> 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 \
| [email protected] http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Wichert Akkerman writes:
> In article <[email protected]>,
> Richard Gooch <[email protected]> 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: [email protected]
Current: [email protected]
Hi,
Richard Gooch <[email protected]> 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.
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
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
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."
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 <[email protected]> /> Northern lights wander \\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
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."
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
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: [email protected]
dean gaudet <[email protected]> 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.
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 <[email protected]> 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.
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.
On 16 Jan 2002, Olaf Dietsche wrote:
> dean gaudet <[email protected]> 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
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 [email protected] GPG: 30F06950
Job Required in Los Angeles - Will do most things unix or IP for money.
http://www.hawaga.org.uk/resume/resume001.pdf
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 - [email protected] - http://www.devcon.net
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 - [email protected] - http://www.devcon.net
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
[email protected]
<>< As a computer I find your faith in technology amusing.
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".
--
................................................................
: [email protected] : 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}...............:
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
dean gaudet <[email protected]> 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.
Ben Clifford <[email protected]> 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.
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 - [email protected] - http://www.devcon.net
Anthony DeRobertis <[email protected]> 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.
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
This idea seems to be popular:
http://www.google.com/search?q=sockfs
I must say I like the idea myself.