Unix domain sockets / IPC - how to get remote process/user id?

[Fossie]

Hi folks,

I am unable to solve the following problem, which should not be new,
but I cannot find an appropriate solution anywhere:

One python process ("daemon") waits for messages. Another python
program ("client"), which is NOT forked off the daemon (but is on the
same Linux machine), sends that message to the daemon.

This of course can be nicely done with Unix domain sockets (AF_UNIX),
but additionally I want the daemon to know the process or user id of
the client. The client could of course include this info in the
message, but then it also could fake it, which I want to prevent.
Therefore it must come somewhere from the kernel.

My hope was that the address returned from socket.recvfrom would help,
but with python 2.3.3 on Debian, the returned address is always None
(a bit odd, python 2.1? at least returned a (meaningless?)
int,emptystring-tupel). I know that Unix domain sockets can return
those info (in structure called credentials), but obviously python
does not handle them?

So, for my question: What are my options? I cannot believe I am the
first with this problem. Preferable, only standard python packages
should be used.

Thanks in advance, Fossie

[Jeff Epler]

On Mon, Feb 09, 2004 at 03:39:34PM -0800, Fossie wrote:

So, for my question: What are my options? I cannot believe I am the
first with this problem. Preferable, only standard python packages
should be used.

My Linux manpage for unix(7) indicates that SCM_RIGHTS is not portable.
(I am not 100% sure this is what you're talking about, because it's
nothing I've ever done before) In any case, I looked but didn't find an
implementation of the needed sendmsg(2) .. I found only this:
https://sourceforge.net/tracker/?fun...&group_id=5470
Wrapping sendmsg with pyrex, ctypes, or even with a new C module might
be a good first project in extending Python. If you do your work in
the form of a patch to Python, I suspect it would easily gain approval.
Once you'd tested your patch and added tests for it, you'd submit the
patch to the bug I mentioned above or as a new item in the Patch area.

best of luck,
Jeff

[Paul Rubin]

go**@fossie.net (Fossie) writes:

So, for my question: What are my options? I cannot believe I am the
first with this problem. Preferable, only standard python packages
should be used.

Unfortunately that capability is missing from the sockets package. I
have a bug in sourceforge about it and was invited to contribute a
patch but haven't gotten around to it. Maybe you'd like to take a turn?

[Paul Rubin]

Jeff Epler <je****@unpythonic.net> writes:

On Mon, Feb 09, 2004 at 03:39:34PM -0800, Fossie wrote:

So, for my question: What are my options? I cannot believe I am the
first with this problem. Preferable, only standard python packages
should be used.

My Linux manpage for unix(7) indicates that SCM_RIGHTS is not portable.
(I am not 100% sure this is what you're talking about, because it's
nothing I've ever done before) In any case, I looked but didn't find an
implementation of the needed sendmsg(2) .. I found only this:
https://sourceforge.net/tracker/?fun...&group_id=5470

Yes, that is the right way to do it, with a patch as suggested in that
bug report.

[Jp Calderone]

On Mon, Feb 09, 2004 at 07:22:30PM -0600, Jeff Epler wrote:

On Mon, Feb 09, 2004 at 03:39:34PM -0800, Fossie wrote:

So, for my question: What are my options? I cannot believe I am the
first with this problem. Preferable, only standard python packages
should be used.

My Linux manpage for unix(7) indicates that SCM_RIGHTS is not portable.
(I am not 100% sure this is what you're talking about, because it's
nothing I've ever done before) In any case, I looked but didn't find an
implementation of the needed sendmsg(2) .. I found only this:
https://sourceforge.net/tracker/?fun...&group_id=5470
Wrapping sendmsg with pyrex, ctypes, or even with a new C module might
be a good first project in extending Python. If you do your work in
the form of a patch to Python, I suspect it would easily gain approval.
Once you'd tested your patch and added tests for it, you'd submit the
patch to the bug I mentioned above or as a new item in the Patch area.

There's a wrapper for sendmsg(2) in Twisted's sandbox:

http://cvs.twistedmatrix.com/cvs/sandbox/pahan/sendmsg/

This may be a good start. It'd be great to have this in the stdlib.

Jp

[Fossie]

Thanks to all for your answers!

I had a look at the sendmsg wrapper from twistedmatrix, but without
any documentation (not even some short comments) it is a bit hard to
use. It seems to support file descriptor passing (SCM_RIGHTS) but
would need some extra coding to support the SCM_CREDENTIAL structure,
which seems to be system dependent anyway, as stated by Jeff (see unix
man page, I had another impression from a short glimpse into Richard
Stevens' networking books..)

All in all, since I am neither a linux nor a network/ipc nor a c
expert [thats why I am using Python ;) ], I was looking more for a
ready-to-use thing.

Therefore, I had a closer look at the system V shared memory (and
semaphore) module (shm), which I found at:
http://gigue.peabody.jhu.edu/~mdboom...ource/shm.html

Its another kind of interprocess communication than I originally
wanted, but does what I need (giving uid/pid) without any
modification. It should be portable (ok, maybe not to windows) and is
good documented (at least sufficiently for me). This looks like a
candidate (useful, portable, documented) for the standard python
library to me..

Thanks again, Fossie