[zeromq-dev] IPC REQ/REP socket unavailable to other users?

[Stewart Douglas]

Could 0MQ be changed to use anonymous sockets which would avoid the file permission issues ? Assuming that's the only permissioning issue.

Stew
-----Original Message-----
From: Pieter Hintjens <ph at imatix.com>
Date: Wed, 11 Aug 2010 16:27:04 
To: 0MQ development list<zeromq-dev at lists.zeromq.org>
Reply-To: 0MQ development list <zeromq-dev at lists.zeromq.org>
Subject: Re: [zeromq-dev] IPC REQ/REP socket unavailable to other users?

Dana,

I'm happy that helped, I'll document it in the user guide.  This is
rather hacky, hopefully we can make 0MQ do that automatically and more
intelligently.  It is standard grief with Unix domain sockets as far
as I know, and changing permissions and uids is the only way around
it.

-Pieter

On Wed, Aug 11, 2010 at 4:14 PM, Dana Leonard <dleonar at gmail.com> wrote:
> Thanks Pieter, that seems to have helped. I now have a work-around but it
> feels super hacky.
>
> My full solution for those paying attention:
>
> Since I want to work under /tmp, this all had to be done programatically. My
> server now mkdir -p's a socket subdirectory and chmod 777's it. The server
> creates and binds the socket in that folder, and then chmod 777's it. The
> server must be run as root (which is fine for my project luckily). If it is
> run as a normal user, the client's still timeout.
>
> It's hard to say whether this is really a ZMQ issue or a UNIX domain socket
> issue. I wish there was a way to research this more, but Google hasn't
> helped much for this kind of socket being used in this way.
>
> On Wed, Aug 11, 2010 at 7:42 AM, Pieter Hintjens <ph at imatix.com> wrote:
>>
>> Hi Dana,
>>
>> This seems to be a standard problem with Unix domain sockets shared
>> between processes that run under different user ids.
>>
>> You might try creating a subdirectory with the right permissions, and
>> creating the sockets within that.
>>
>> If that does not help, please post an issue to the Git issue tracker,
>> with simple sample code to reproduce the problem.  0MQ would need to
>> modify the socket permissions after creating the socket and before
>> binding.
>>
>> Regards
>> Pieter
>>
>>
>> On Tue, Aug 10, 2010 at 9:00 PM, Dana Leonard <dleonar at gmail.com> wrote:
>> > Hi everyone,
>> >    I've found a strange socket behavior on a Red Hat linux box today.  I
>> > have a server process that opens an IPC REQ/REP socket that is used to
>> > accept association requests from clients. Clients can use this socket
>> > just
>> > fine, as long as the client process is executed by the same user who
>> > executed the server. For example: User A starts the server. User A
>> > starts a
>> > client process and it associates with the server fine. User B starts
>> > another
>> > client, and it fails while connecting to the socket.
>> >
>> >    Is this a standard behavior for IPC sockets on Unix or does the
>> > socket
>> > need additional configuration to allow different users to use it? I have
>> > tried changing the permissions on the socket to 777 to no avail. Even
>> > root
>> > cannot use a socket created by another user. Has anyone run into this
>> > before
>> > and figured out how to fix it?
>> >
>> >    By the way, the "run everything as the same user" solution does not
>> > fit
>> > the requirements of our project.
>> >
>> > Thanks,
>> > Dana
>> >
>> >_______________________________________________
>> > 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