Comment 17 for bug 586546

Re #14 (Dustin Kirkland):

Thanks; "ssh -t server bash" is a workaround I had somehow failed to notice. I suggest that it should be documented somewhere very obvious if byobu becomes enabled by default though.

Re #16 (Timothy R. Chavez):

> Anyone with access to my user account effectively has
> access to the root user as well because when they log
> in as me, byobu-launcher will attach them to the existing
> session which is currently sitting in a root shell.

Good point in that byobu does effectively subvert the per-tty tickets of sudo: a byobu session will contain a persistent tty and thus sudo tickets will be shared amongst separate ssh connections.

However I have never quite been convinced by sudo's security model in this regard (and this is equivalent to the scenario you present where a root shell is left open inside byobu): if someone gains access to a sysadmin's personal account, it is a simple matter for the attacker to surreptitiously install hooks such that the next time the sysadmin elevates to root (via sudo, or su, or anything else) the attacker elevates to root too.

So in my opinion byobu bypasses a bogus security feature... maybe this makes things slightly easier for the attacker but not considerably so.

> The other concern I have has to do w/ automation. I
> could imagine some organization has written a set of
> expect scripts (why!?)

I echo the "(why!?)" -- running expect on a shell is pretty bizaare and not something I would worry about. Shell scripts are a much saner approach and if invoked sensibly, e.g.

  ssh user@host some-remote-script.sh

or even like

  ssh user@host < some-local-script.sh

byobu will not be invoked as bash will not be running interactively and so .bash_profile will not be sourced.

(NB: these opinions are entirely mine and I certainly don't speak for the byobu maintainers or Ubuntu.)