4 ms·

Yup, screen -x

qwertox 1y ago
The problem isn't with the use of `screen -x ...` itself, but rather if `ls -l "$(which screen)"` returns something like `-rwsr-xr-x 1 root root ... /usr/bin/screen`, where the `s` in the fourth position indicates the setuid bit is set. That means the screen binary runs with root privileges.
- trollied 1y ago
  I am well aware of setuid. I was informing the parent comment of which arg to use for the actual functionality.
  - radlad 1y ago
    I was surprised to hear OP wasn't aware of it as it was the first reason I ever had to use screen (shared remote debugging session.)
    - esseph 1y ago
      Often for long running jobs you want to see the status of where logging out of the system stops the job output.
      - qwertox 1y ago
        Or where you can't risk dropping the terminal session, like during a system upgrade via SSH.
        esseph 1y ago
        System upgrade shouldn't drop your session btw, at least not on most flavors I'm familiar with
        ycombobreaker 1y ago
        The risk is anything else dropping your connection while an interactive long-running process is going. You can nohup, or run inside something like screen/tmux,
        throwaway173738 1y ago
        A thoughtfully designed upgrade system doesn’t do the real work side your terminal session in the interactive process.
        ycombobreaker 1y ago
        Defense in depth is always valuable. The point of this thread is that screen protects your workflow from an unexpected disconnection.
        esseph 1y ago
        You're not wrong, but largely in the virtualized world we live in, it matters less and less when you have a virtual console. That said the sshd session you are connected on is still running the old executable until the service is restarted AND your session ends, so even if sshd gets upgraded, you should still be good to go.
    - magicalhippo 1y ago
      I use screen almost by default when connecting over SSH, but I've never used -x and didn't know about it. Habbit from back in the dial-up days when connections got dropped quite frequently. Still relevant with laptop going into sleep mode and such. So nice to just resume wherever you were as of nothing happened. Or to run jobs in the background, like long compiles, without an additional SSH session.

Yup, screen -x

The problem isn't with the use of `screen -x ...` itself, but rather if `ls -l "$(which screen)"` returns something like `-rwsr-xr-x 1 root root ... /usr/bin/screen`, where the `s` in the fourth position indicates the setuid bit is set. That means the screen binary runs with root privileges.

trollied 1y ago
I am well aware of setuid. I was informing the parent comment of which arg to use for the actual functionality.
- radlad 1y ago
  I was surprised to hear OP wasn't aware of it as it was the first reason I ever had to use screen (shared remote debugging session.)
  - esseph 1y ago
    Often for long running jobs you want to see the status of where logging out of the system stops the job output.
    - qwertox 1y ago
      Or where you can't risk dropping the terminal session, like during a system upgrade via SSH.
      - esseph 1y ago
        System upgrade shouldn't drop your session btw, at least not on most flavors I'm familiar with
        ycombobreaker 1y ago
        The risk is anything else dropping your connection while an interactive long-running process is going. You can nohup, or run inside something like screen/tmux,
        throwaway173738 1y ago
        A thoughtfully designed upgrade system doesn’t do the real work side your terminal session in the interactive process.
        ycombobreaker 1y ago
        Defense in depth is always valuable. The point of this thread is that screen protects your workflow from an unexpected disconnection.
        esseph 1y ago
        You're not wrong, but largely in the virtualized world we live in, it matters less and less when you have a virtual console. That said the sshd session you are connected on is still running the old executable until the service is restarted AND your session ends, so even if sshd gets upgraded, you should still be good to go.
  - magicalhippo 1y ago
    I use screen almost by default when connecting over SSH, but I've never used -x and didn't know about it. Habbit from back in the dial-up days when connections got dropped quite frequently. Still relevant with laptop going into sleep mode and such. So nice to just resume wherever you were as of nothing happened. Or to run jobs in the background, like long compiles, without an additional SSH session.