search

sudo-project / sudo

Utility to execute a command as another user
https://www.sudo.ws
Other
1.19k stars 220 forks source link

Ask some questions about the process model：There are two distinct ways sudo can run a command. #217

Closed BornThisWay closed 1 year ago

BornThisWay commented 1 year ago

I've read the implementation of sudo_execute many times, but there's still a lot of confusion. It's mainly about suspension and resumption.

int sudo_execute(struct command_details *details, struct command_status *cstat)

bool exec_pty(struct command_details *details, struct command_status *cstat)

void exec_nopty(struct command_details *details, struct command_status *cstat)
  1. If the command is paused because it receives SIGTSTP, sudo will also send this signal to itself, Who is handling the SIGTSTP of sudo? Default handling by the signal system? or signal_cb_pty (or signal_cb_nopty)? but I don't see the code in signal_cb_pty (or signal_cb_nopty).
  2. If sudo does suspend, who will notify it of the resumption and how? (notty + tty) In scenarios where tty is required: The code says: /* Suspend parent and tell monitor how to resume on return. */ But，I didn't see how
  3. The sudo.man says "This makes it possible to suspend and resume the command." in scenarios where tty is required. But I see that they(tty + notty) handle Command suspension scenario very similarly in their code. Why distinguish between the two models when both can be paused?

I don't think I can get out on my own :D, I'm looking forward to your reply.

millert commented 1 year ago

  1. When sudo is suspended, it is the responsibility of sudo's parent process to handle it. In most cases a shell is sudo's parent process. For example, if you were to run "sudo vi" and suspend vi, control would return to the shell.

  2. When sudo is resumed by the shell (or whatever the parent process is), it picks up right where it left off. In other words, it resumed immediately after the call to kill() that suspended it.

  3. The pty and nopty code used to use a common event loop but the code was difficult to follow due to lots of if (log_io) { ... } else { ... } type constructs. Now that the nopty event loop also supports I/O logging it might be possible to re-unify them but some things, such as signal handling, are still quite different.