Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #96841

Re: Shutting down a cross-platform multithreaded app

References <mthgrk$uh1$1@dont-email.me> <CAPTjJmqw26YfJs12q6C_a_JYhQks6RmLhL=0A7OCy5jcGpaBug@mail.gmail.com> <1442612909.2539807.387692137.0E9C2446@webmail.messagingengine.com>
Date 2015-09-19 08:09 +1000
Subject Re: Shutting down a cross-platform multithreaded app
From Chris Angelico <rosuav@gmail.com>
Newsgroups comp.lang.python
Message-ID <mailman.11.1442614161.21674.python-list@python.org> (permalink)

Show all headers | View raw


On Sat, Sep 19, 2015 at 7:48 AM, Random832 <random832@fastmail.com> wrote:
> On Fri, Sep 18, 2015, at 17:40, Chris Angelico wrote:
>> Bear in mind, though, that Windows has no protection against other
>> processes shutting you down.
>
> Neither does Unix. Any process that can send you a signal can send you
> SIGKILL.

Incorrect. If your server is running as root, only root can kill it:

rosuav@sikorsky:~$ kill -9 17080
bash: kill: (17080) - Operation not permitted

If it's running as some other user, then that user can kill it (that
includes the simple case where a non-root user starts a process and
also tries to kill it), as can root, of course. So you have protection
against direct signals (and not just 9/KILL, naturally); and you also
have protection against an AF_UNIX socket, which is what I was talking
about here. The control over sockets is a bit more flexible, as I'm
fairly sure group permissions can't be set for process signals, but
they can for named sockets:

rosuav@sikorsky:~$ python3
Python 3.6.0a0 (default:30bc256f2346, Sep 17 2015, 02:01:45)
[GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
>>> s.bind("/tmp/demo_socket")
>>> import os
>>> os.chmod("/tmp/demo_socket",0o750)
>>> s.listen(1)
>>> s.accept()
# program pauses here
(<socket.socket fd=4, family=AddressFamily.AF_UNIX,
type=SocketKind.SOCK_STREAM, proto=0, laddr=/tmp/demo_socket>, b'')

In another terminal, using Python 2 for variety:

rosuav@sikorsky:~$ sudo sudo -u tfr python
Python 2.7.9 (default, Mar  1 2015, 12:57:24)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> s = socket.socket(socket.AF_UNIX)
>>> s.connect("/tmp/demo_socket")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/socket.py", line 224, in meth
    return getattr(self._sock,name)(*args)
socket.error: [Errno 13] Permission denied

Err, nope! What if I don't change users?

rosuav@sikorsky:~$ python
Python 2.7.9 (default, Mar  1 2015, 12:57:24)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> s = socket.socket(socket.AF_UNIX)
>>> s.connect("/tmp/demo_socket")
>>>

Looks good. (Feel free to concoct your own scenario that proves that
group permissions work here; I don't have any handy demo cases.)

Unix is designed for this exact sort of thing. Windows isn't, and
privilege escalation attacks are far more common there.

> Of course, what Windows lacks is a generalized way for other processes
> to send "less destructive" signals that do give you a chance to clean
> up. (You can sometimes send a ctrl-break event, but that's it.) And most
> frameworks for "emulating" them (including python's os module) simulate
> sending other signals by calling TerminateProcess with an exit status
> related to the signal.

Yeah, the whole notion of less-destructive (or even completely
non-destructive - look at how a lot of daemons use SIGHUP) signals is
absent on Windows. But that's not really the problem here; the problem
is that there's no way to say "this is a socket for my process ONLY",
which in Unix would be done with a socket.socketpair, but on Windows I
think has to be simulated.

That said, though.... socket.socketpair() IS supported on Windows...
as of Python 3.5. I haven't tested it to see what it's like. If you
can restrict your support to 3.5+, you might be able to do this
instead of what I was describing above.

ChrisA

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Shutting down a cross-platform multithreaded app "James Harris" <james.harris.1@gmail.com> - 2015-09-18 18:17 +0100
  Re: Shutting down a cross-platform multithreaded app Paul Rubin <no.email@nospam.invalid> - 2015-09-18 11:23 -0700
    Re: Shutting down a cross-platform multithreaded app "James Harris" <james.harris.1@gmail.com> - 2015-09-18 20:09 +0100
      Re: Shutting down a cross-platform multithreaded app Laura Creighton <lac@openend.se> - 2015-09-18 22:50 +0200
        Re: Shutting down a cross-platform multithreaded app "James Harris" <james.harris.1@gmail.com> - 2015-09-19 10:56 +0100
  Re: Shutting down a cross-platform multithreaded app Marko Rauhamaa <marko@pacujo.net> - 2015-09-18 23:40 +0300
  Re: Shutting down a cross-platform multithreaded app Chris Angelico <rosuav@gmail.com> - 2015-09-19 07:40 +1000
    Re: Shutting down a cross-platform multithreaded app "James Harris" <james.harris.1@gmail.com> - 2015-09-19 10:49 +0100
      Re: Shutting down a cross-platform multithreaded app Chris Angelico <rosuav@gmail.com> - 2015-09-19 20:14 +1000
        Re: Shutting down a cross-platform multithreaded app "James Harris" <james.harris.1@gmail.com> - 2015-09-19 11:48 +0100
          Re: Shutting down a cross-platform multithreaded app Chris Angelico <rosuav@gmail.com> - 2015-09-19 20:59 +1000
  Re: Shutting down a cross-platform multithreaded app Random832 <random832@fastmail.com> - 2015-09-18 17:48 -0400
  Re: Shutting down a cross-platform multithreaded app Chris Angelico <rosuav@gmail.com> - 2015-09-19 08:09 +1000
  Re: Shutting down a cross-platform multithreaded app Akira Li <4kir4.1i@gmail.com> - 2015-09-19 02:56 +0300

csiph-web