1. 6
  1.  

  2. 6

    This essentially spawns a separate python interpreter loaded with the child_script and calls the decorated function inside it, marshalls the data then grabs it from the spawned interpreter and unmarshalls in the main app.

    Looks handy but I think it’s far less optimal and more risky than just adding sudo to a normal subprocess call to an executable and could lead to some amazingly akward ways people try to use it.

    Things I can imagine going wrong:

    1. The whole python code is ran as the elevated user
    2. People might use it to open a user restricted file and they will be surprised that the file handle can’t be used
    3. It’s a lot of overhead if the intention is to just call a normal executable. You are suddenly spawning a python process as an elevated user only to spawn a command from it

    It is a cool & clever hack but I don’t see a real use cases for it.

    1. 1

      I think of it more as a showcase of tricks you can do with marshal and func_code — not the corners of Python you visit every day, for sure.

    2. 0

      If your program has a need for privilege escalation, it might be worth examining how your life has ended up where it has.

      1. 1

        Perhaps it needs it because it’s a system tool that’s meant to be ran as root? Makes sense to me, I don’t know.

        1. 1

          I guess I think that programs that need uid 0 should be run as uid 0, and programs that don’t, oughtn’t. Too, a program that needs uid 0 is probably dealing with a configuration that can and should be changed. I don’t think that there are many programs that absolutely need uid 0.