[zeromq-dev] IPC path permissions

Joe McIlvain joe.eli.mac at gmail.com
Fri Feb 13 19:16:28 CET 2015 

Santosh,

I took a quick look at this, and there is a problem with this approach.

The `zmq_connect` function returns "immediately" and the internal `connect`
system call happens asynchronously in an I/O thread.  This is why you
weren't able to figure out how to raise the errno up to `zmq_connect`.
Furthermore, after playing with this a bit I've found I was incorrect to
assume that the current behavior benefits no-one.  Because the actual
connection to the unix socket happens asynchronously, this allows for the
connecting socket to 'wait' until it actually can access the file.  This
means that you can zmq_connect to a file location that does not exist or
you do not have permissions for, start a zmq_recv waiting, then create the
file location or alter its permissions from another process, and the
connecting socket will actually be able to receive sent data.

I imagine that we can't have the behavior you describe without breaking
contracts for those who rely on being able to connect to a socket that does
not exist yet so that they don't have to worry about races and ensuring the
zmq_bind happens first.

If it helps you, zmq_bind actually will raise EACCESS, so you might think
about trying to invert your connect/bind topology if you really need this
behavior.


On Fri, Feb 13, 2015 at 9:27 AM, <Santosh_Bidaralli at dell.com> wrote:

> Hi Joe,
>
>
>
> Please pardon my knowledge on C++, I have very limited experience on C++.
>
> I tried to look into the ZMQ source code and was not able to figure out
> how to capture the return error from connect() and pass it all the way to
> zmq_connect().
>
>
>
> It would be very helpful if you can create the patch and share it with the
> community for a faster approach.
>
>
>
> Thanks,
>
> Santosh
>
>
>
> *From:* zeromq-dev-bounces at lists.zeromq.org [mailto:
> zeromq-dev-bounces at lists.zeromq.org] *On Behalf Of *Joe McIlvain
> *Sent:* Wednesday, February 11, 2015 3:37 PM
>
> *To:* ZeroMQ development list
> *Subject:* Re: [zeromq-dev] IPC path permissions
>
>
>
> Santosh,
>
>
>
> Sounds like a good change to me.  I can't imagine anyone relying on the
> current behavior, because they wouldn't be able to communicate over that
> socket anyway.
>
>
>
> Care to submit a patch on Github?
>
>
>
>
>
> On Wed, Feb 11, 2015 at 1:19 PM, <Santosh_Bidaralli at dell.com> wrote:
>
> Hi Pieter and Jim,
>
> I got the trace of the client using strace command to find out what is
> going on and below is the log. You can observe that connect is actually
> failing with appropriate error "EACCESS", however ZMQ function continues
> without failure.
> Do you think it is good idea to catch this error in ZMQ lib and fail the
> zmq_connect()?
>
>  [pid  3574] socket(PF_LOCAL, SOCK_STREAM, 0) = 9
> [pid  3574] fcntl64(9, F_SETFD, FD_CLOEXEC) = 0
> [pid  3574] fcntl64(9, F_GETFL)         = 0x2 (flags O_RDWR)
> [pid  3574] fcntl64(9, F_SETFL, O_RDWR|O_NONBLOCK) = 0
> [pid  3574] connect(9, {sa_family=AF_LOCAL,
> sun_path="/var/run/ipcs/broker.ipc"}, 110) = -1 EACCES (Permission denied)
> [pid  3574] close(9)                    = 0
> [pid  3574] clock_gettime(CLOCK_MONOTONIC, {99606, 898670000}) = 0
> [pid  3574] read(6, "\1\0\0\0\0\0\0\0", 8) = 8
> [pid  3574] poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout)
> [pid  3574] clock_gettime(CLOCK_MONOTONIC, {99606, 903637000}) = 0
> [pid  3574] epoll_wait(7,  <unfinished ...>
> [pid  3572] <... write resumed> )       = 8
> [pid  3572] write(8, "\1\0\0\0\0\0\0\0", 8) = 8
> [pid  3572] write(1, "dzmq_sync_ots_rcv_msg: Connected"...,
> 93dzmq_sync_ots_rcv_msg: Connected successfully to endpoint
> [ipc:///var/run/ipcs/broker.ipc]
>
> Thanks,
> Santosh
>
> -----Original Message-----
> From: zeromq-dev-bounces at lists.zeromq.org [mailto:
> zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Pieter Hintjens
>
> Sent: Tuesday, February 10, 2015 3:06 PM
> To: ZeroMQ development list
> Subject: Re: [zeromq-dev] IPC path permissions
>
> It's been a while since this was discussed, and I'm not sure of the
> current state of master.
>
> You can use the ZMQ_IPC_FILTER_GID socket option. This is marked as
> "deprecated" and afair the GID, UID, and PID are sent via ZAP in case it's
> an IPC connection. However I've not tested that and vaguely recall that it
> never got implemented.
>
> -Pieter
>
> On Tue, Feb 10, 2015 at 9:55 PM,  <Santosh_Bidaralli at dell.com> wrote:
> > Pieter,
> >
> > We will be using ZAP authentication framework for the external clients,
> however in our case we also have internal clients that run with different
> Unix based user and group ids. Hence we would like to detect and deny the
> requests sent by the processes that do not belong to Broker's group id.
> >
> > Thanks,
> > Santosh
> >
> > -----Original Message-----
> > From: zeromq-dev-bounces at lists.zeromq.org
> > [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Pieter
> > Hintjens
> > Sent: Tuesday, February 10, 2015 1:42 PM
> > To: ZeroMQ development list
> > Subject: Re: [zeromq-dev] IPC path permissions
> >
> > You can do real authentication, there is a framework for this, called
> > ZAP, and you can see how it works from ZeroMQ RFC 27,
> > http://rfc.zeromq.org/spec:27 and the various test cases like
> tests/test_security_null.cpp. You can also see examples of ZAP handler in
> CZMQ's zauth class.
> >
> > On Tue, Feb 10, 2015 at 8:31 PM,  <Santosh_Bidaralli at dell.com> wrote:
> >> Thanks for the response Pieter. However our requirement is to fail when
> an unauthorized user tries to connect with broker, so we would like to
> detect and deny an invalid user trying to connect.
> >>
> >> Thanks,
> >> Santosh
> >>
> >> -----Original Message-----
> >> From: zeromq-dev-bounces at lists.zeromq.org
> >> [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Pieter
> >> Hintjens
> >> Sent: Tuesday, February 10, 2015 12:40 PM
> >> To: ZeroMQ development list
> >> Subject: Re: [zeromq-dev] IPC path permissions
> >>
> >> If you are running on Linux I'd strongly advise using abstract IPC
> endpoints, which don't need special permissions. "ipc://@/somename".
> >>
> >>
> >> On Tue, Feb 10, 2015 at 7:07 PM,  <Santosh_Bidaralli at dell.com> wrote:
> >>> Hi All,
> >>>
> >>>
> >>>
> >>> I am trying to create broker based client-server apps by referring
> >>> to ZMQ guide. I am unable to detect IPC path permission error when
> >>> an invalid user tries to connect using zmq_connect().
> >>>
> >>>
> >>>
> >>> Following steps explain the test scenario in detail:
> >>>
> >>> 1.       Create a ZMQ broker that stores its IPC socket in a directory
> >>> “/var/run/ipcs”
> >>>
> >>> a.       ZMQ broker runs with a specific user and group (ex: zuser and
> >>> zgroup respectively)
> >>>
> >>> b.      “/var/run/ipcs” has permissions for all the users that belong
> to
> >>> “zgroup” (permissions = drwxrws---)
> >>>
> >>> c.       IPC path example “ipc:///var/run/ipcs/broker.ipc”
> (permissions =
> >>> drwxrws---)
> >>>
> >>>
> >>>
> >>> 2.       Create a service provider that listens to request from broker
> >>>
> >>> a.       Service provider runs as a user “zservice” that belongs to
> “zgroup”
> >>>
> >>>
> >>>
> >>> 3.       Create a client that connects to ZMQ broker’s IPC path
> >>> “ipc:///var/run/ipcs/broker.ipc” and sends the requests
> >>>
> >>> a.       If the client runs with a user that belongs to “zgroup”
> everything
> >>> works fine
> >>>
> >>> b.      If the client runs with invalid a user such as “nobody” that
> does
> >>> not belong to “zgroup”, it does not return any error. In turn
> >>> zmq_connect() and zmq_send() returns success and zmq_recv() waits
> >>> forever (ZMQ_REP socket).
> >>>
> >>>
> >>>
> >>> Can you please let me know how do I get an appropriate error such as
> >>> “Permission Denied” in case of an invalid user trying to connect to
> >>> broker’s IPC?
> >>>
> >>>
> >>>
> >>> Thanks,
> >>>
> >>> Santosh Bidaralli
> >>>
> >>>
> >>> _______________________________________________
> >>> zeromq-dev mailing list
> >>> zeromq-dev at lists.zeromq.org
> >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >>>
> >> _______________________________________________
> >> zeromq-dev mailing list
> >> zeromq-dev at lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >> _______________________________________________
> >> zeromq-dev mailing list
> >> zeromq-dev at lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150213/607b9af5/attachment.htm>

More information about the zeromq-dev mailing list