Ticket #646 (closed defect: wontfix)

Opened 10 years ago

Last modified 10 years ago

repy allows catching exceptions that, if caught, could prevent process termination

Reported by: jsamuel Owned by: jsamuel
Priority: minor Milestone:
Component: repy Version: 0.1l
Severity: Medium Keywords:
Cc: justinc Blocking:
Blocked By:


The following exceptions, if caught by user repy code, could prevent a shutdown that was supposed to happen:


I don't think our code will normally give the user a shot at SystemExit (and obviously not KeyboardInterrupt) as we generally use os._exit() or os.kill() rather than sys.exit(). However, I'm not 100% certain a SystemExit could never pass through user code and removing the ability to catch it would be a preventative measure.

It looks like the other exception that could prevent an exit, BaseException, isn't in the list. I would guess this allowed exception list was created before python 2.5 when BaseException was added.

However, actually removing the ability to catch specific exceptions by removing the exception names from safe.py's _BUILTIN_OK list doesn't actually do any good unless we also remove the use of except: without a specific exception type.

Without these changes, the namespace api function wrappers being implemented should at least provide a layer of protection against user code getting a chance to catch SystemExit.

Change History

Changed 10 years ago by jsamuel

  • priority changed from major to minor

Changed 10 years ago by justinc

  • cc justinc added

I assume that in the case of SystemExit?, this has already been addressed. If the only other risk here is KeyboardInterrupt?, I think we can close this as wontfix.

Can you update this ticket?

Changed 10 years ago by jsamuel

  • status changed from new to closed
  • resolution set to wontfix

The namespace layer doesn't yet do anything special with SystemExit. The reason for this is largely that the right course of action isn't obvious and the risk here is quite low. Just calling harshexit doesn't make much sense because if SystemExit is really being raised, it could be due to a bug in harshexit, possibly someone used sys.exit in harshexit (which they shouldn't be doing). One option would be try harshexit, if it raises SystemExit then try os._exit (which according to comments in the code doesn't work in all cases), and if execution still proceeds then raise SystemExit again and let the user code have it's chance to still catch it in that case, which means we still haven't entirely solved the problem.

Or we could just not worry about it because we don't use sys.exit in api code so it should never happen, and if it did there really isn't much to worry about. This ticket was mostly to spill thoughts on the topic and I've thought about it and now am not really concerned.

Closing it as wontfix. Feel free to repoen it if you think that the above steps (or possibly a better suggestion) should be implemented in the namespace layer.

Note: See TracTickets for help on using tickets.