[zeromq-dev] Associating messages to authenticated clients

[Goswin von Brederlow]

On Tue, Jan 21, 2014 at 07:04:07AM -0600, Pieter Hintjens wrote:
> On Tue, Jan 21, 2014 at 5:17 AM, Goswin von Brederlow <goswin-v-b at web.de> wrote:
> 
> > I played around with that and you can test it:
> > https://github.com/mrvn/libzmq/tree/mrvn
> >
> > So far the code compiles (for me). I haven't had time to write a
> > proper test case for it yet. But I've modifed tests/test_security_curve.cpp
> > to call zmq_msg_get_user_id() and that seems to work:
> 
> Awesome... could you push this as a pull request so we can play with
> it. Please check https://github.com/zeromq/libzmq/issues/802 where we
> were discussing this.
> 
> I'd like to be able to access all sender metadata for a message,
> eventually, and allow clients to set metadata before connecting.
> 
> Breaking the zmq_msg_t structure is problematic, it means recompiling
> applications as the size is defined in zmq.h.
> 
> Perhaps we could add a new type, zmq_frame_t, for this, and take the
> opportunity to fix that msg/frame fuzziness.
> 
> -Pieter

This is just a first try and not ready to be merged. There are still
several unresolved issues, like:

1) ABI breakage.

I added the mechanism pointer to the message itself increasing its
size and breaking ABI. That is a big problem.

There are, so far, 2 possible solutions to this:

a) only messages with contents need the pointer so the pointer could
be moved into the union next to the content pointer. Afaik there is
enough space there for it so the message structure doesn't have to
grow.

b) replace the FD field with a pointer to the socket base. The socket
base then has the FD and a pointer to the mechanism so both can be
accessed.


What do you think? Does it make more sense to store the socket base?


2) memory management

I beliefe the mechanism structure is destroyed when a peer
disconnects. This would cause an unaceptable race condition with
retrieving the user_id or credentials from a message. The mechanism
pointer could become invalid at any point.

I think the mechanism structure must be extended to have a reference
count. Every message has to increment the count when the mechanism
pointer is stored and decrement it when the message is closed or the
pointer is otherwise reset. Similar for any other holder of a pointer
to the mechanism, which would be the socket base, right?

A mechanism structure would free itself when the count reaches 0.

Note: When storing socket base pointers (1b) that would need reference
counting.


3) API to access metadata, properties, ...

I'm not sure how metadata and properties are suposed to be set and
used. Should each have their own retrieval function? Or is one generic
function similar to getsockopt enough? Maybe user_id and metadata
should even just be another property?

I just added zmq_msg_get_user_id() as a proof-of-concept. Seemed to be
the simplest thing to test the idea.


4) write access to the metadata

The user_id, metadata and properties can be set in the ZAP handler.
But should that be the only palce they can be set? Maybe the
application will want to set additional state or modify the data. Or
is that infeasable because the data would silently get lost on
reconnect?


MfG
	Goswin