Messages in this thread | | | Date | Thu, 18 Sep 1997 15:39:41 -0500 (CDT) | From | Jay Schulist <> | Subject | Re: 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
| |