Interprocess communication on multi-user machine

Discussion in 'Python' started by Michael Butscher, Jun 29, 2006.

  1. 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/
     
    Michael Butscher, Jun 29, 2006
    #1
    1. Advertising

  2. 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=9f563aeb2e5639cf574

    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:9f563aeb2e5639cf574

    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
     
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Jun 29, 2006
    #2
    1. Advertising

  3. In article <44a41cae$0$29145$-online.net>,
    Michael Butscher <> 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.
     
    Lawrence D'Oliveiro, Jun 30, 2006
    #3
  4. In article <>,
    Lawrence D'Oliveiro <_zealand> writes:
    |> In article <44a41cae$0$29145$-online.net>,
    |> Michael Butscher <> 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, Jun 30, 2006
    #4
  5. In article <44a41cae$0$29145$-online.net>,
    Michael Butscher <> 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.
     
    Nick Maclaren, Jun 30, 2006
    #5
  6. In article <e82tbu$grc$>,
    (Nick Maclaren) wrote:

    >In article <>,
    >Lawrence D'Oliveiro <_zealand> writes:
    >|> In article <44a41cae$0$29145$-online.net>,
    >|> Michael Butscher <> 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.
     
    Lawrence D'Oliveiro, Jun 30, 2006
    #6
  7. In article <>,
    Lawrence D'Oliveiro <_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.
     
    Nick Maclaren, Jun 30, 2006
    #7
  8. In article <e8323i$r79$>,
    (Nick Maclaren) wrote:

    >In article <>,
    >Lawrence D'Oliveiro <_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...
     
    Lawrence D'Oliveiro, Jul 1, 2006
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Swapnajit Mittra
    Replies:
    0
    Views:
    448
    Swapnajit Mittra
    Dec 21, 2004
  2. Dave Bartlett

    newbie question: interprocess communication

    Dave Bartlett, May 13, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    495
    DalePres
    May 13, 2004
  3. James  Aguilar
    Replies:
    3
    Views:
    556
    Aguilar, James
    Dec 20, 2005
  4. exhuma.twn
    Replies:
    23
    Views:
    1,040
    Steve Holden
    Feb 18, 2007
  5. Charles Packer

    Interprocess communication: which scenario?

    Charles Packer, Dec 20, 2004, in forum: C Programming
    Replies:
    4
    Views:
    370
Loading...

Share This Page