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.