lkml.org 
[lkml]   [1997]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: sockfs - a filesystem for reserved port permissions
Hello,
Just from following this thread it seems the big reason to have the sockfs
is to set permissions on different sockets.

I personally would not like to have a seperate filesystem for sockets, I
find that it is not needed. Although I would agree that being able to set
permissions on sockets would be very nice.

Unless there is some other compelling reason that I don't see, why not
just implement socket permissions in the socket layer in the kernel
directly? I am sure this route would be greatly accepted.

My two cents worth.

On Thu, 18 Sep 1997, Andy Bakun wrote:

> I have not taken a look at the patch in depth yet, but...
>
> What about after mounting sockfs, it appears as an empty dir, meaning that
> permissions are set defaultly (root only below 1024). Then, say I want
> user frank to be allowed to bind to port 80 on IP 1.2.3.4. So I mkdir
> /sockfs/1.2.3.4 and touch /sockfs/1.2.3.4/80. I can then chown
> /sockfs/1.2.3.4/80 to frank, as described. If I touch /sockfs/80, then I'm
> setting up permissions for port 80 on all IP aliases. Add dirs somewhere for
>
> This will, of course, add some overhead at permission creating time, but it
> will get rid of that 6k (?) structure keeping track of the (mostly sparse)
> port permissions. It would be easier to get a general picture of the
> current permissions setup also, because you only have to look at (and keep
> track of) what has changed from the norm, rather than this huge list of ports.
>
> I'll go back to lurking now... :)
>
> At 04:15 PM 9/18/97 +0100, Malcolm Beattie <mbeattie@sable.ox.ac.uk> wrote:
> >> > Here's sockfs, a little pseudo-filesystem that lets you set the
> >> > owner/group/permissions for reserved ports just by using
> >> > chown/chgrp/chmod and ls. I wrote it a few weeks ago as an
> >
> >I don't think it's really suitable for this, although I did think
> >about it. sockfs, since it applies only to bind(), only has to
> >worry about one end of the connection. Furthermore, it currently
> >doesn't distinguish between multiple local addresses (so you can't
> >set permissions such that username foo can only bind to port 666
> >on one IP alias and not another). That would be doable with more
> >effort: the kernel would need to call the hook and pass in the
> >address too and the filesystem would have to have another level
> >(/sockfs/1.2.3.4/666) and would probably have to keep track
> >dynamically of IP aliases: blech.
> >
> >I've made it fairly easily extensible to families other than
> >AF_INET if they have a concept of "privileged ports" (if there
> >are any)--the filesystem would then look like /sockfs/inet/666.
> >
> >Writing the file operations so that they do clever things like
> >opening connections would need extra bits of information such as
> >remote address passed out of band so you wouldn't really be able
> >to use standard user-mode tools anyway. And if you're going to
> >have to write/tweak user-mode tools you might as well stick with
> >the standard socket API and use something like netcat or an URL
> >library anyway.
>
>

Jay Schulist
Jay.Schulist@spacs.k12.wi.us
SPACS Network Developer


\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.037 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site