[bind10-dev] Socket creator and low-level code

[Michal 'vorner' Vaner]

Hello

On Fri, Oct 22, 2010 at 04:52:43PM +0200, Shane Kerr wrote:
> No dictate, I think we can discuss this a little bit more still. Sorry!

We surely can discuss. It's just that I'll need to dump my ideas and current
status soon before I forget them. It would be small save of work if it was code,
not English ;-).

> > So, what do you think? Does it make sense to change the use of the read/write to
> > a template functions, eliminate type casts and clean it up of pointer as much as
> > possible for me?
> 
> When I was thinking about this earlier, I had two basic ideas on how to
> approach the problem:
> 
>      1. Fixed-sized binary protocol.
>      2. Line-based text protocol.
> 
> My approach to the binary protocol was something like:
> 
>         'T'/'U'          -> TCP or UDP, 1 byte
>         '4'/'6'          -> IPv4 or IPv6, 1 byte
>         AAAAAAAAAAAAAAAA -> address (0-padded for IPv4), 16 bytes
>         PP               -> port, 2 bytes
> 
> So we always send exactly 20 bytes. My thinking is that this would
> simplify both sending and receiving. We can guarantee that the client &
> server stay in sync by always sending full packets.

Hmm, that makes sense. Well, better say sending a struct with this content
(which can have paddings, so it could possibly be different than 20 bytes).
Maybe, if it would help not to have pointers, both 16-byte IPv6 and 4-byte IPv4
could be present so we do not need to overlay them/store IPv4 in buffer of wrong
length…

Is keeping them in sync any real problem?

I guess this one is slightly better if the protocol doesn't need any way of
extensibility in future. But then, both sides could be updated anyway.

>    tcp\n
>    172.29.1.193\n
>    53\n

Seems better than single-line ones. But yes, these need some kind of stdio or
iostream and in that case there's a problem where to put the created socket,
because they possibly buffer data.

> In both cases someone who hacks the client process can allocate
> arbitrary ports and cause mischief that way, but I don't think we can
> avoid that.

Well, if someone is able to run any code inside any of the processes, even when
run on normal user, it is much worse than being able to allocate small ports.

Anyway, I was thinking about if we could use some capabilities to fine-tone its
privileges (eg. drop everything except the ability to allocate small ports).

Have a nice day

-- 
chown -R us $BASE

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20101023/b46ab218/attachment.bin>