[zeromq-dev] IPC path permissions

Fri Feb 13 18:27:53 CET 2015

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<mailto: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> [mailto: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<mailto: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>
> [mailto: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<mailto: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>
>> [mailto: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<mailto: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<mailto:zeromq-dev at lists.zeromq.org>
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org<mailto:zeromq-dev at lists.zeromq.org>
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org<mailto:zeromq-dev at lists.zeromq.org>
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org<mailto:zeromq-dev at lists.zeromq.org>
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org<mailto:zeromq-dev at lists.zeromq.org>
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev at lists.zeromq.org<mailto:zeromq-dev at lists.zeromq.org>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev at lists.zeromq.org<mailto: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/3466cce9/attachment.htm>