Hi, if you want to hide the socket from global namespace, there are at least two options (before using containers) on Linux
Call unshare (2) and CLONE_NEWIPC/CLONE_NEWNET to create your private network namespace in a broker, so the ipc or tcp sockets won't be globally visible. You must exec the child plugins from the main process. http://man7.org/linux/man-pages/man2/unshare.2.html Alternatively you can use systemd's features PrivateNetwork/JoinsNamespaceOf to perform the same. But then broker and plugins must be managed using systemd https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateNetwork= I am not aware about anything portable to other platforms. On Tue, May 31, 2016 at 8:06 PM, Jim Garlick <[email protected]> wrote: > On Tue, May 31, 2016 at 05:47:24PM +0100, Luca Boccassi wrote: >> On Tue, 2016-05-31 at 08:52 -0700, Jim Garlick wrote: >> > On Mon, May 30, 2016 at 09:57:00PM +0200, Michal Vyskocil wrote: >> > > Hi, >> > > >> > > Awesome, the fact czmq handles that is good enough for me. Closed the >> > > request. >> > > On Mon, 2016-05-30 at 21:14 +0200, Michal Vyskocil wrote: >> > > > Hi, >> > > > >> > > > Ale's thread about Setting privileges on a UNIX socket inspired me to >> > > > create small patch to libzmq adding automatic systemd socket >> > > > activation support. >> > > > https://github.com/zeromq/libzmq/pull/2015 >> > > > >> > > > Right now the feature is fairly minimal - limited to ipc transport - >> > > > and tested manually using malamute broker. I would like to hear any >> > > > feedback. If you consider it as useful (or want to avoid dependency on >> > > > the most hated OSS software on the planet ;-)), please say so. >> > > >> > > Hi, >> > > >> > > That functionality is already implemented for both IPC and TCP sockets. >> > > >> > > The low level library has the ZMQ_USE_FD socket option to pass a file >> > > descriptor, and the high level CZMQ has ZSYS_AUTO_USE_FD env var or >> > > zsys_set_auto_use_fd(1) function to let zmq automatically match >> > > endpoints to the corresponding sockets managed by systemd. As long as >> > > the metadata matches (eg: file path for IPC, address + port for TCP), it >> > > will just work out of the box. >> > > >> > > Kind regards, >> > > Luca Boccassi >> > >> > Somehow I missed that - sounds useful! >> > >> > Is the usual reconnect behavior disabled when this option is present, >> > or is that what the aforementioned metadata is used for? I couldn't >> > find the answer in >> > http://api.zeromq.org/4-2:zmq-setsockopt >> > >> > or in the note about reconnect exceptions in >> > http://api.zeromq.org/4-2:zmq-connect >> > >> > Thanks, >> > >> > Jim Garlick >> >> Hi, >> >> This is used only for server-ish sockets - ie, all those that do any >> sort of bind and you would use with zmq_bind, so it does not affect >> zmq_connect (or re-connect). >> >> I thought about adding it for the connect side too, but IMHO it wouldn't >> make much sense. The purpose of systemd-managed sockets is to let >> servers be started only when a client attempts to connect, and to >> disentangle dependencies between services and allow them to start in >> parallel at boot, while having systemd manage the FD buffer so that no >> messages are lost in either scenario. >> Neither of these would apply for client-ish sockets. >> >> But we can of course look into it, do you have a use case where it would >> be useful to have? >> >> Kind regards, >> Luca Boccassi > > Ah, thanks for the clarification. > > Well, there are probably other ways to accomplish my use case. > We have a broker that loads "plugins" as threads communicating with > the broker over a per-plugin ZMQ_PAIR inproc:// socket. > We'd like to be able to launch plugins as processes with fork/exec. > What I had in mind when I heard about ZMQ_USE_FD was something like > ZMQ_PAIR over file descriptors obtained with socketpair(), one end > passed to plugin, one end retained by broker. > > Having an endpoint that doesn't appear in any namespace simplifies > life a bit compared to ipc:// or tcp:// - it wouldn't need to be > protected against unauthorized access for example. > > Jim > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev -- best regards Michal Vyskocil _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
