Bug#639687: roxterm fails to open new tab/window if current tab has root-owned shell
On Fri, 02 Sep 2011 08:57:41 +0400 Michael Tokarev m...@tls.msk.ru wrote: Yes, that's the most obvious thing to do - to ignore certain errors, or maybe even _all_ errors in this place - it is one of very rare cases where error handling actually may be omitted ;) It was actually a little more complicated than that. I had read that readlink() returns NULL here on Solaris so the best thing to do there was use /proc/N/cwd without following the link. But ignoring the error causes problems later on in Linux, as you've found, so I've had to check that too. I don't know whether it still works in Solaris :-/. And yes I'm certain that previous versions had no such issue - it always opened new window in previous directory in such situation. It actually wasn't always a good idea anyway: eg, I can run su from some random directory (it will go stright to root's $HOME), but roxterm will continue to open new tabs/windows in that random directory, even if it makes no sence anymore. I understand that roxterm just can't know if that's the case - with older way to track current dir changes. But that's all history now. It now passes NULL to the spawn function. I assumed that would cause it to use whatever the cwd was when roxterm was launched, regardless of what other terminals have been using, but that doesn't seem to be the case: 1. Open a terminal (starting cwd = ~); cd roxterm 2. Open a new tab; cd src; exec su 3. Open a new tab: cwd is roxterm Quite unexpected! So I think using $HOME would be a good idea. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639687: roxterm fails to open new tab/window if current tab has root-owned shell
On Mon, 29 Aug 2011 17:08:49 +0400 Michael Tokarev m...@tls.msk.ru wrote: The sequence of events is like, open a roxterm window as user, su to root with exec (exec su - or exec sudo bash) open new tab or window (Ctrl+Shift+N or Ctrl+Shift+T) it will complain that it can't read /proc/NN/cwd due to permission denied problem and close new window/tab after confirmation dialog. I understand it is trying to get current working directory of a child process to start new tab/window in the same dir, and it fails because new child is root-owned and it can't read its current directory anymore. In this case it may either notice this fact in a dialog or just use $HOME silently, instead of failing. I think previous version had no issue like this. Thanks for the report. I can confirm this is reproducible and I've fixed it by checking for errors (eg EPERM) reading the link and not trying to set the cwd in that case. You're probably right that previous versions didn't have this bug because they spawned child processes in a different way. I've fixed it in git but I'd rather hold off release for a little while. I've only just released a new version (experimental in Debian) and it would be surprising if there aren't any other bugs because there were major changes. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639687: roxterm fails to open new tab/window if current tab has root-owned shell
On 01.09.2011 18:02, Tony Houghton wrote: On Mon, 29 Aug 2011 17:08:49 +0400 Michael Tokarev m...@tls.msk.ru wrote: The sequence of events is like, open a roxterm window as user, su to root with exec (exec su - or exec sudo bash) open new tab or window (Ctrl+Shift+N or Ctrl+Shift+T) it will complain that it can't read /proc/NN/cwd due to permission denied problem and close new window/tab after confirmation dialog. [] Thanks for the report. I can confirm this is reproducible and I've fixed it by checking for errors (eg EPERM) reading the link and not trying to set the cwd in that case. You're probably right that previous versions didn't have this bug because they spawned child processes in a different way. Yes, that's the most obvious thing to do - to ignore certain errors, or maybe even _all_ errors in this place - it is one of very rare cases where error handling actually may be omitted ;) And yes I'm certain that previous versions had no such issue - it always opened new window in previous directory in such situation. It actually wasn't always a good idea anyway: eg, I can run su from some random directory (it will go stright to root's $HOME), but roxterm will continue to open new tabs/windows in that random directory, even if it makes no sence anymore. I understand that roxterm just can't know if that's the case - with older way to track current dir changes. But that's all history now. I've fixed it in git but I'd rather hold off release for a little while. I've only just released a new version (experimental in Debian) and it would be surprising if there aren't any other bugs because there were major changes. Fair enough, I've seen your discussion about roxterm, roxterm-legacy, roxterm-glib3 et all on debian-devel. And I haven't asked for an urgent fix - I hope it was quite obvious, especially having in mind that I've choosen severity to be minor... ;) Thank you for your time and efforts! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639687: roxterm fails to open new tab/window if current tab has root-owned shell
Package: roxterm Version: 1.22.2-1 Severity: minor The sequence of events is like, open a roxterm window as user, su to root with exec (exec su - or exec sudo bash) open new tab or window (Ctrl+Shift+N or Ctrl+Shift+T) it will complain that it can't read /proc/NN/cwd due to permission denied problem and close new window/tab after confirmation dialog. I understand it is trying to get current working directory of a child process to start new tab/window in the same dir, and it fails because new child is root-owned and it can't read its current directory anymore. In this case it may either notice this fact in a dialog or just use $HOME silently, instead of failing. I think previous version had no issue like this. Severity is minor because it isn't often when you exec an su or sudo in a terminal. Thanks, /mjt -- System Information: Debian Release: 6.0.2 APT prefers stable APT policy: (990, 'stable'), (600, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.0.3-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages roxterm depends on: ii libc6 2.13-16 Embedded GNU C Library: Shared lib ii libdbus-1-31.2.24-4+squeeze1 simple interprocess messaging syst ii libdbus-glib-1-2 0.88-2.1 simple interprocess messaging syst ii libgdk-pixbuf2.0-0 2.23.5-3 GDK Pixbuf library ii libglade2-01:2.6.4-1 library to load .glade files at ru ii libglib2.0-0 2.28.6-1 The GLib library of C routines ii libgtk2.0-02.24.4-3 The GTK+ graphical user interface ii libice62:1.0.6-2 X11 Inter-Client Exchange library ii libpango1.0-0 1.28.3-1+squeeze2 Layout and rendering of internatio ii librsvg2-common2.34.0-1 SAX-based renderer library for SVG ii libsm6 2:1.1.1-1 X11 Session Management library ii libvte91:0.28.1-2Terminal emulator widget for GTK+ ii libx11-6 2:1.3.3-4 X11 client-side library Versions of packages roxterm recommends: ii openssh-client1:5.5p1-6 secure shell (SSH) client, for sec roxterm suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
