The comments at the end of issue #673 shows an example where sshuttle
exits with an OSError exception when it cannot bind to an IPv6
address. This patch makes a suggestion to try the --disable-ipv6
option instead of the cryptic error message.
Commit d6f75fa unintentionally changed the order of some of the
parameters when running the firewall process. This prevented the
--sudoers option from working properly. This patch restores the
previous ordering.
Most discussion was in issue #724. Also fixes#722 and #723.
If we run sudo with the use_pty option, the firewall process is
started in a new pseudoterminal. Other processes that are still
printing to the terminal (i.e., the main sshuttle client process,
messages from the shuttle server) have their output incorreclty
displayed. A newline character simply moves the output to the next
line without returning the cursor to the beginning of the line. Simply
changing all print commands to use \r\n line endings fixes the problem
and does not appear to cause any trouble in other configurations.
We previously called setsid() to ensure that the SIGINT generated by
Ctrl+C went to the main sshuttle process instead of the firewall
process. With the previous commit, we gracefully shutdown if either
the sshuttle process or firewall process receives a SIGINT. Therefore,
the setsid() call is optional. We still try calling setsid() since the
preferred shutdown process involves having the signal go to the main
sshuttle process. However, setsid() will fail if the firewall process
is started with sudo and sudo is configured with the use_pty option.
Typically sshuttle exits by having the main sshuttle client process
terminated. This closes file descriptors which the firewall process
then sees and uses as a cue to cleanup the firewall rules. The
firewall process ignored SIGINT/SIGTERM signals and used setsid() to
prevent Ctrl+C from sending signals to the firewall process.
This patch makes the firewall process accept SIGINT/SIGTERM signals
and then in turn sends a SIGINT signal to the main sshuttle client
process which then triggers a regular shutdown as described above.
This allows a user to manually send a SIGINT/SIGTERM to either
sshuttle process and have it exit gracefully. It also is needed if
setsid() fails (known to occur if sudo's use_pty option is used) and
then the Ctrl+C SIGINT signal goes to the firewall process.
The PID of the sshuttle client process is sent to the firewall
process. Using os.getppid() in the firewall process doesn't correctly
return the sshuttle client PID.
When we flush the DNS cache by calling resolvectl, we should wait for
the process to finish. This ensures that the cache is actually flushed
and prevents the process from showing up as defunct when processes are
listed.
When the tproxy method is used, sshuttle must be run as root:
https://sshuttle.readthedocs.io/en/stable/tproxy.html
Prior to this patch, sshuttle would encounter a exception and print a
message about how a setsockopt() call had a "PermissionError: [Errno 1]
Operation not permitted."
With this patch, we catch this exception, print a more understandable
error message, and exit.
The lack of error message clarity caused at least one bug report: #136
This is an alternative solution to pull request #611.
Previously, sshuttle would use doas on OpenBSD and sudo on Linux.
However, some Linux distributions are opting to use doas.
This patch changes the logic so that there can be multiple attempts to
elevate privilages. If the first command fails to run, it moves on to
the next command. Part of the existing code looked like it might be
attempting to do this, but it didn't work.
It also looks for the presence of doas and sudo in the path. If we can
find doas (but cannot find sudo) or if the platform is OpenBSD, we try
doas first. Otherwise, we try sudo, then doas. We try all the options
until one succeeds (including running the command without sudo or
doas) regardless of what is in the path. I'm open to adjusting
the logic here based on feedback.
If systems have both sudo and doas, they might be configured to give
different users different permissions. For example, if a user wishes
to use doas on this system, sshuttle would try sudo first and the user
would need to enter invalid passwords to eventually cause sudo to fail
and cause sshuttle to then try doas. This might not be ideal, but it
avoids implement another sshuttle argument that the user would need to
specify. Perhaps machines actually using doas will not have sudo
installed?
