Interprocess communication on multi-user machine

[Michael Butscher]

Hi,

this is not really Python-specific but I need it for Python.

I'm wanting a method for interprocess communication which is OS-
independent (sockets would be the normal way to go), but which works if
multiple users use the machine at the same time so that one user has no
access to the communication of programs of another user.

Normally any user could connect to an open socket on a machine
regardless which user established the socket (the user's program, to be
precise). This should be prevented.

I could solve this with an additional login when connecting to socket
but this would be uncomfortable for the user.

Any hints?

TIA

Michael
--
Homepage: http://www.mbutscher.de/

[Martin v. Löwis]

Michael Butscher wrote:

I'm wanting a method for interprocess communication which is OS-
independent (sockets would be the normal way to go), but which works if
multiple users use the machine at the same time so that one user has no
access to the communication of programs of another user.

Any hints?

The conventional solution is to use environment variables or well-known
temporary files for that. For example, the file could look like this

port=45413
cookie=9f563aeb 2e5639cf574

Put the file into a per-user location, and hope that this "good enough"
to separate users. If access control is a must, you need
platform-specific code to deny read access to the file to anybody
but the user.

Alternatively, put the port number and the cookie into an environment
variable, e.g.

FOO_PORT=45413: 9f563aeb2e5639c f574

This is technically better protected (practically, environment
variables might easier leak, e.g. when somebody types "env").
However, this works well only if you manage to set this up
for the entire user session, else you have to ask the user to
manually duplicate the environment variable in all shells
he cares about.

In case this isn't clear yet: the cookie should then be used
for authentication. Only trusted clients would know the right
cookie.

Regards,
Martin

[Lawrence D'Oliveiro]

In article <44************ ***********@new sread4.arcor-online.net>,
Michael Butscher <mb*******@gmx. de> wrote:

Normally any user could connect to an open socket on a machine
regardless which user established the socket (the user's program, to be
precise).

That's not true. On *nix systems, a socket is a file, and is subject to
the usual file ownership and protection mechanisms.

[Nick Maclaren]

In article <ld************ ***********@lus t.ihug.co.nz>,
Lawrence D'Oliveiro <ld*@geek-central.gen.new _zealand> writes:
|> In article <44************ ***********@new sread4.arcor-online.net>,
|> Michael Butscher <mb*******@gmx. de> wrote:
|>
|> >Normally any user could connect to an open socket on a machine
|> >regardless which user established the socket (the user's program, to be
|> >precise).
|>
|> That's not true. On *nix systems, a socket is a file, and is subject to
|> the usual file ownership and protection mechanisms.

I am afraid that BOTH answers are badly wrong!

Sockets are often accessed via special files, but are not files.
They may also be accessed by port numbers, for example.

Secondly, even when they are accessed via files, FIFOs generally
do NOT use the usual file ownership and protection mechanisms to
control access. Blame Berkeley for that :-( It is normal for the
actual file ownership and permissions to be ignored, and a similar
set (hidden internally) to be used. You are right that there is
almost always such control.

While any user can attempt to open any socket accessed by port
number, the rules for when it is permitted are complicated to a
degree, and depend on the system, configuration and program that
is listening on that port.
Regards,
Nick Maclaren.

[Nick Maclaren]

In article <44************ ***********@new sread4.arcor-online.net>,
Michael Butscher <mb*******@gmx. de> writes:
|>
|> this is not really Python-specific but I need it for Python.
|>
|> I'm wanting a method for interprocess communication which is OS-
|> independent (sockets would be the normal way to go), but which works if
|> multiple users use the machine at the same time so that one user has no
|> access to the communication of programs of another user.

You're onto a complete loser if you really mean that. But you are
probably meaning Unix-like systems (including Microsoft ones), and
excluding the systems that are not based on or largely cloned from
Unix. You should look at the POSIX facilities, but don't rely on
them without checking.

Also think very carefully whether you want to separate by user or
job - the latter is trickier under Unix.
Regards,
Nick Maclaren.

[Lawrence D'Oliveiro]

In article <e8**********@g emini.csx.cam.a c.uk>,
nm**@cus.cam.ac .uk (Nick Maclaren) wrote:

In article <ld************ ***********@lus t.ihug.co.nz>,
Lawrence D'Oliveiro <ld*@geek-central.gen.new _zealand> writes:
|> In article <44************ ***********@new sread4.arcor-online.net>,
|> Michael Butscher <mb*******@gmx. de> wrote:
|>
|> >Normally any user could connect to an open socket on a machine
|> >regardless which user established the socket (the user's program, to be
|> >precise).
|>
|> That's not true. On *nix systems, a socket is a file, and is subject to
|> the usual file ownership and protection mechanisms.

I am afraid that BOTH answers are badly wrong!

Sockets are often accessed via special files, but are not files.
They are files. They are not _regular_ files.
They may also be accessed by port numbers, for example.
UNIX sockets have no ports.
Secondly, even when they are accessed via files, FIFOs generally
do NOT use the usual file ownership and protection mechanisms to
control access.
I wasn't talking about FIFOs. Even if I was, they _are_ still subject to
regular file permissions (on Linux, at least).
While any user can attempt to open any socket accessed by port
number...

UNIX sockets have no ports.

[Nick Maclaren]

In article <ld************ ***********@lus t.ihug.co.nz>,
Lawrence D'Oliveiro <ld*@geek-central.gen.new _zealand> writes:
|> >
|> >Sockets are often accessed via special files, but are not files.
|>
|> They are files. They are not _regular_ files.

Sigh. Firstly, look at something like:

http://www.opengroup.org/onlinepubs/009695399/toc.htm

Start at the entry 'socket' and work from there.

Yes, I know about UNIX-domain sockets, but even when they give the
appearance of being files, 90% of the time that is the API only,
and the underlying facility is very different. Dammit, processes
are not files just because they happen to have a /proc entry under
many systems!

|> >They may also be accessed by port numbers, for example.
|>
|> UNIX sockets have no ports.

You mean "UNIX-domain", not "UNIX". So? Many sockets do. Internet-
domain ones always do.

|> I wasn't talking about FIFOs. Even if I was, they _are_ still subject to
|> regular file permissions (on Linux, at least).

They aren't on most Unices - Linux is not UNIX, you know :-)
I shall not respond further on this.
Regards,
Nick Maclaren.

[Lawrence D'Oliveiro]

In article <e8**********@g emini.csx.cam.a c.uk>,
nm**@cus.cam.ac .uk (Nick Maclaren) wrote:

In article <ld************ ***********@lus t.ihug.co.nz>,
Lawrence D'Oliveiro <ld*@geek-central.gen.new _zealand> writes:
|> >
|> >Sockets are often accessed via special files, but are not files.
|>
|> They are files. They are not _regular_ files.

Yes, I know about UNIX-domain sockets, but even when they give the
appearance of being files, 90% of the time that is the API only,
and the underlying facility is very different.
Irrelevant. The userland API requires accessing a file, which is subject
to standard *nix file ownerships and protections.
Dammit, processes
are not files just because they happen to have a /proc entry under
many systems!
They are files. They have all the semantics of files. Under Linux they
are in fact directories, but those are still files.

They are not files with blocks allocated on some physical disk
partition, but that doesn't make them any the less files.
|> I wasn't talking about FIFOs. Even if I was, they _are_ still subject to
|> regular file permissions (on Linux, at least).

They aren't on most Unices - Linux is not UNIX, you know :-)
I'm not aware of any *nix system worthy of the name where they are not.
The "everything-is-a-file" concept is deeply ingrained into the whole
*nix philosophy.
I shall not respond further on this.

One can hope...