I would like to add a new feature to zeromq to filter incoming IPC connections. This is especially useful when using abstract Unix domain sockets on Linux because there is no way to set file permissions on an abstract socket. But it is also useful for one to set permissive permissions on a file-based socket and restrict access based on application configuration.
This feature will be implemented using getsockopt with SO_PEERCRED on Linux and LOCAL_PEERCRED on OS X to get information about the owner of the peer socket and determine whether access should be granted within the application.
The suggested mechanism will work similar to ZMQ_TCP_ACCEPT_FILTER. One may set users and groups to whom access will be granted via zmq_setsockopt. On Linux, process identifiers (PIDs) are also supported so that child processes may be forked and access to an IPC channel restricted to those processes. OS X does not supply the peer process identifier. If no accept filters are set, access is unrestricted and the filter list may be cleared just as for ZMQ_TCP_ACCEPT_FILTER.
I would like feedback on the recommended way to pass these options via zmq_setsockopt and on whether zeromq should handle resolving names to their IDs or leave that as a user exercise.
One approach is to define three new socket options: ZMQ_IPC_ACCEPT_FILTER_PID, ZMQ_IPC_ACCEPT_FILTER_UID, and ZMQ_IPC_ACCEPT_FILTER_GID where an integer is expected for the option value. If zeromq handles name resolution, then the ZMQ_IPC_ACCEPT_FILTER_USER and ZMQ_IPC_ACCEPT_FILTER_GROUP options could also be defined to accept a string that will be resolved to the appropriate UID or GID and added to the internal filter list. This approach simplifies the interface for setting filters at the expense of adding many new options.
A second approach would be to define a single ZMQ_IPC_ACCEPT_FILTER option which takes the following structure as the option value:
Of course there is another option, but I don't think it will be a hit: allow registering a callback and let the programmer do all the dirty work. So ZMQ_IPC_ACCEPT_FILTER would accept a callback similar to int (*filter)(int socket) where the OS socket file descriptor is passed to the filter function and a value indicating acceptance or rejection is returned.
Please leave comments regarding which approach is recommended and whether name-to-ID resolution should be supported by zeromq or if zeromq should only expect IDs.
Brandon Carpenter
Minor
I would like to add a new feature to zeromq to filter incoming IPC connections. This is especially useful when using abstract Unix domain sockets on Linux because there is no way to set file permissions on an abstract socket. But it is also useful for one to set permissive permissions on a file-based socket and restrict access based on application configuration.
This feature will be implemented using getsockopt with SO_PEERCRED on Linux and LOCAL_PEERCRED on OS X to get information about the owner of the peer socket and determine whether access should be granted within the application.
The suggested mechanism will work similar to
ZMQ_TCP_ACCEPT_FILTER. One may set users and groups to whom access will be granted via zmq_setsockopt. On Linux, process identifiers (PIDs) are also supported so that child processes may be forked and access to an IPC channel restricted to those processes. OS X does not supply the peer process identifier. If no accept filters are set, access is unrestricted and the filter list may be cleared just as forZMQ_TCP_ACCEPT_FILTER.I would like feedback on the recommended way to pass these options via zmq_setsockopt and on whether zeromq should handle resolving names to their IDs or leave that as a user exercise.
One approach is to define three new socket options:
ZMQ_IPC_ACCEPT_FILTER_PID,ZMQ_IPC_ACCEPT_FILTER_UID, andZMQ_IPC_ACCEPT_FILTER_GIDwhere an integer is expected for the option value. If zeromq handles name resolution, then theZMQ_IPC_ACCEPT_FILTER_USERandZMQ_IPC_ACCEPT_FILTER_GROUPoptions could also be defined to accept a string that will be resolved to the appropriate UID or GID and added to the internal filter list. This approach simplifies the interface for setting filters at the expense of adding many new options.A second approach would be to define a single
ZMQ_IPC_ACCEPT_FILTERoption which takes the following structure as the option value:Of course there is another option, but I don't think it will be a hit: allow registering a callback and let the programmer do all the dirty work. So
ZMQ_IPC_ACCEPT_FILTERwould accept a callback similar toint (*filter)(int socket)where the OS socket file descriptor is passed to the filter function and a value indicating acceptance or rejection is returned.Please leave comments regarding which approach is recommended and whether name-to-ID resolution should be supported by zeromq or if zeromq should only expect IDs.
Thank you.