Bug#781176: byobu: fails to start when using shared NFS home
Hi, I don't have an NFS home directory on a Debian host, but I have run byobu on non-Debian systems with an NFS home directory and not had this problem. I also don't see any files in ~/.byobu that indicate state. No, there aren't. The information whether a session is running is determined by the byobu wrapper by examining the output of the backend's standard way of listing running sessions. The rest of the state is maintained in /dev/shm/byobu-$USER. This fails at the point where it tries to get to its state in /dev/shm: /usr/lib/byobu/include/dirs:52: no matches found: /dev/shm/byobu-nik-* mkdir: cannot create directory „/cache.tmux“: Permission denied The “no matches found” message hints to me (via codesearch.d.n) that you may have zsh set as /bin/sh, is that correct? I'm not saying there's anything wrong with that, but that may be provoking some unexpected behavior here. Can you try running with /bin/sh set temporarily to dash or bash and see if the error goes away? This is, in that case, completely unrelated. /bin/sh points to dash here, it was never set to anything else. The issue results solely from tmux list-sessions returning a session running on another host and byobu then trying to blindly read /dev/shm/byobu-$USER. I think this might be related to some misconfiguration of the NFS root somewhere, but still byobu should not try to use files blindly without checking for errors. -nik -- Dominik George (Vorstandsvorsitzender, Pädagogischer Leiter) Teckids e.V. - Erkunden, Entdecken, Erfinden. https://www.teckids.org signature.asc Description: Digital signature
Bug#781176: byobu: fails to start when using shared NFS home
On Wed, Aug 26, 2015 at 22:57:51 -0400, Mike Miller wrote: On Wed, Mar 25, 2015 at 18:21:20 +0100, Dominik George wrote: This fails at the point where it tries to get to its state in /dev/shm: /usr/lib/byobu/include/dirs:52: no matches found: /dev/shm/byobu-nik-* mkdir: cannot create directory „/cache.tmux“: Permission denied The “no matches found” message hints to me (via codesearch.d.n) that you may have zsh set as /bin/sh, is that correct? Nevermind, I can reproduce at least this part of your report with SHELL=/bin/zsh, no NFS home directory required. Enabling byobu to start automatically is the same as running SHELL=/bin/zsh _byobu_sourced=1 zsh --interactive -c . /usr/bin/byobu-launch which shows the error messages you report, if I don't already have an existing /dev/shm/byobu-$LOGNAME-whatever directory. The zsh default is to fail on globs that do not match, which explains why this error only shows in zsh. Other than these error messages, what exactly is the bad behavior you've observed? Does byobu actually fail to start as the title implies? Or is this simply about the attempt to create and use the /cache.tmux directory? Thanks, -- mike
Bug#781176: byobu: fails to start when using shared NFS home
Control: tags -1 + moreinfo Hi, On Wed, Mar 25, 2015 at 18:21:20 +0100, Dominik George wrote: The actual result is byobu wreaking havoc because it finds a running session in ~/.byobu and tries to join it. I don't have an NFS home directory on a Debian host, but I have run byobu on non-Debian systems with an NFS home directory and not had this problem. I also don't see any files in ~/.byobu that indicate state. This fails at the point where it tries to get to its state in /dev/shm: /usr/lib/byobu/include/dirs:52: no matches found: /dev/shm/byobu-nik-* mkdir: cannot create directory „/cache.tmux“: Permission denied The “no matches found” message hints to me (via codesearch.d.n) that you may have zsh set as /bin/sh, is that correct? I'm not saying there's anything wrong with that, but that may be provoking some unexpected behavior here. Can you try running with /bin/sh set temporarily to dash or bash and see if the error goes away? thanks, -- mike
Bug#781176: byobu: fails to start when using shared NFS home
control: severity -1 important On Wed, Mar 25, 2015 at 1:21 PM, Dominik George wrote: This bug is possibly security relevant because the intention of the script, namely separating user directories in /dev/shm, is entirely defeated. As a matter of lucky fact, / is not writable by regular users. However, this will break even more once root decides to use byobu and succeeds in creating /cache.tmux (or whatever byobu will create for other backends). Please find out whether this is exploitable in any way. Poor behavior by apps running as root does not automatically imply security relevance. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781176: byobu: fails to start when using shared NFS home
Package: byobu Version: 5.87-1 Severity: serious Justification: possible user security hole -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Byobu fails to behave well in an environment where multiple hosts share home directories through NFS. Doing the following provokes malicious behaviour: 1. Set byobu to automatically start on login 2. Login to host A and let byobu set up its environment 3. Login to host B in some way, with host B using the same home directory The expected result would be byobu running flawlessly on both hosts. The actual result is byobu wreaking havoc because it finds a running session in ~/.byobu and tries to join it. This fails at the point where it tries to get to its state in /dev/shm: /usr/lib/byobu/include/dirs:52: no matches found: /dev/shm/byobu-nik-* mkdir: cannot create directory „/cache.tmux“: Permission denied There are at least two bugs: 1. byobu should not try to join a session running on another host 2. Failure to find the /dev/shm directory should result in immediate failure, not have byobu go on with an empty variable and try to create stuff in / This bug is possibly security relevant because the intention of the script, namely separating user directories in /dev/shm, is entirely defeated. As a matter of lucky fact, / is not writable by regular users. However, this will break even more once root decides to use byobu and succeeds in creating /cache.tmux (or whatever byobu will create for other backends). Please find out whether this is exploitable in any way. - -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages byobu depends on: ii debconf [debconf-2.0] 1.5.55 ii gawk 1:4.1.1+dfsg-1 ii gettext-base 0.19.3-2 ii python 2.7.8-4 ii python-newt0.52.17-1+b1 ii screen 4.2.1-3 ii tmux 1.9-6 Versions of packages byobu recommends: pn run-one none ii screen 4.2.1-3 ii tmux 1.9-6 Versions of packages byobu suggests: pn apport none pn cczenone ii lsb-release 4.1+Debian13+nmu1 ii po-debconf 1.0.16+nmu3 pn ttf-ubuntu-font-family none pn update-notifier-common none ii vim 2:7.4.488-4 pn w3m none pn wireless-tools none - -- debconf information: byobu/launch-by-default: false -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJOBAEBCAA4BQJVEu6QMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pY5jg/+ILvnidZ4h8l1jSSC+B02 G1vIQqq41BKjNnnZBdL2hPFmmD2Nn6pK0xYrARNMDh9hKMbOC6RqXwl5+iiT3GSZ CsDbFpW5bG6KYwaBsMMSTPLh3D6XjHKkbyEmYuPDX4mO2tg066TjmjQXZwFAZfY+ 1wjbBvVnwQNku4BuI0xtNDUAh2gXiPNCY8p0kyQLg3ScofteyEZntysoPF3Q4gfA FZnLwECrz7h0hlrGgO7fAcCB4hPOag/Gv6mNcqqIzNuL+nvc9LIKkGIBEH6lCIMn x9o5M4rZmX5AuxsYS/8q8yKN0Hvl0/FOVOzJYObr+uS0m4s34QHbFJAdfJUG51ZV VScdU9VupvpJJ4yqBFdWK+4FcGZO6HuEMM0FuRaAknBBxtRRpwUZRadgl4vr9UgQ QpBLyotkiXJUR+C8Tbcp6inAHEX9eIqrdE0+IQqKTYmRGuh/V8uCiq42AbrPeJr7 dS/neqMrBYCTRRpABzXuvquBuyehWtwiv9EzS+LM1qORbLHBjE4MJr+nfk1kbQRP w00fy5VQT4bg+IqLyrAhCXIBZNzHTmDOJhHHF6SCm8fSvoCsQkuPEIK0j5VERre+ iDRFjl0DxQ7wa09X8WdQazEPv5M+FP8c6dnIYKvnWI8wp8luZtwc7OYMuMfEUm10 lbG5by1gE9RPDEiDZzwq7rA= =sd4f -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
