以sudo方式运行python调用

Question

We have a python setup script which was run as root, currently we want to run it from as sudoer user, with a set of privileges. The problem is that our code is full of os.makedirs and open(filename) etc.

open(filename) as sudo ?
os.makedirs as sudo ?
... as sudo ?

Solutions which are not suitable for us:

1. Run the whole setup script as "sudo python script.py" This is a security problem for us. We need to avoid it.

2. Popen(["sudo","..."]) This is bad for non-unix systems support, and requires all the code to be rewritten.

Answer 1

I have beef with requirement #2. How is it that you need sudo but you also need to be platform agnostic? If that's really what you want, you must re-think requirement #1, OR detect which OS you're on and prefix your commands with sudo if you are on *nix. Also, aside from running the whole script using sudo, you're going to have to change code, so that part of #2 is a mute point. Using sudo in Popen commands, however, is kind of pointless. You will have to enable passwordless sudo for those specific commands which you must run, and IMO that's more of a risk than just running the whole script with UID 0. However, it seems you're only interacting with the filesystem, which as someone commented does raise the question of could you just give your user permission to access the files it needs?

Tl;dr Give the user running the program permissions to access these files, or step back and ask yourself why you're having this issue and is this really the best solution to your problem

Answer 2

In general, when a small piece of your code has to be run with elevated privileges, but it's not safe to run the rest this way, you do something like this:

You run your main script as root. But at startup, it forks or spawns a child process (which is still root), then immediately drops privileges. When you need to do something as root, you use some sufficiently-safe IPC mechanism (a socketpair may or may not be sufficiently-safe, depending on the rest of your design…) to ask the child to do it on your behalf and send back a response. The details are a little different for Windows, but the same basic idea can be made to work.

---

There are alternatives to this, however, including:

• Create setuid programs, and run them as children from a non-root parent. This one isn't workable on Windows, and may not be appropriate on Unix when you're dealing with child scripts.
• Redesign your app into a daemon/service, which is separately managed (typically by your system's daemon/service manager) and runs as root, and the main app, which talks to the daemon over IPC.
• Store credentials that can be used to impersonate root as needed (ideally just on a short-lived child process or thread). This one works great on Windows, but doesn't work so well on Unix.

---

However, in this case, there's a much simpler solution: The only thing you seem to need root privileges for is to read (and maybe write?) files that you installed as owned by a different user. Just make those files group-readable (and maybe -writable), and run the script as a limited-privilege user who's a member of that group.