I noticed today that xfce4-terminal uses the unlink tmp file/but keep the file handle open technique. And of all things, it uses this for terminal buffer contents. I realize that the data has to be somewhere, but first of all this puts the data on disk and it seems pretty trivial to write a script to scrape someone's terminal buffers. I think this should be fixed so that it no longer uses tmp files on the file system for buffer data. Steps to reproduce: 1. Open a couple of xfce4-terminal windows 2. Run ls in one of them, find / in another, etc. 3. As the same user or as root run: find /proc/$(pgrep xfce4-terminal | head -1)/fd/ -ls | grep deleted | awk '{print $(NF-3)}' | xargs cat | less -R I tried a handful of other popular terminal software and the only other ones on Linux that I could find that has this symptom is gnome-terminal and guake. Is xfce4-terminal based on gnome-terminal's code? Older terminals like xterm, rxvt, aterm and Eterm all use sockets and pipes I guess and probably put all the buffer in memory. Konsole seems to do things securely as well as Yakuake, which is probably based on it. Honestly, I thought this is the way all terminals did it and I never dreamed that some were storing terminal buffer contents on disk. I think a lot of people would be surprised by this. Actually, running strings on my /tmp filesystem shows quite a bit of old terminal contents.
UPDATE: this is starting to look like a problem within VTE. I found the code within the VTE library that managed these deleted tmp files.
Indeed handled by vte, but maybe we do something wrong with vte.
Already reported upstream in vte?
(In reply to comment #3) > Already reported upstream in vte? Hi! This was reported twice on the GNOME bugtracker: https://bugzilla.gnome.org/show_bug.cgi?id=631685 https://bugzilla.gnome.org/show_bug.cgi?id=664611 And there was a patch proposed (not clear if really applied) for Ubuntu: https://bugs.launchpad.net/ubuntu/+source/vte/+bug/778872
Keeping the buffers on disk has multiple aspects. A quick heads-up on the current state in Vte-3 (cf. bug 11207): - Security/privacy sensitive data remaining on disk: vte-0.40 addresses this by applying strong encryption. - Disk getting full: vte-0.40 helps here by compressing the scrollback contents, leading to a typical 3-4x shrink. A decision had to be made here whether it's better to run out of RAM (which is often a bit scarce resource, potentially bringing the whole machine down) vs run out of disk space (which you usually have much more of, and there's some reserved area for root) vs dropping a popular feature of infinite scrollback. The decision was that probably it's still the best to store the contents on disk. - Constant disk access (and potential hdd wakeups in some setups) is still an issue. For those who'd prefer to have it in memory: it's possible by setting vte's TMPDIR to some shm/tmpfs location. It's up to xfce-terminal to maybe display a warning next to where the user sets the scrollback size.
(In reply to Egmont Koblinger from comment #5) > For those who'd prefer to have it in memory: it's possible by setting vte's > TMPDIR to some shm/tmpfs location. How can I set vte's TMPDIR, please? And also, wouldn't changing the default TMPDIR from /tmp to /dev/shm solve the issue?
(In reply to Teresa e Junior from comment #6) > How can I set vte's TMPDIR, please? I guess a simple export TMPDIR=/whatever before starting xfce-terminal (in a wrapper script probably) should do it. > And also, wouldn't changing the default TMPDIR from /tmp to /dev/shm solve > the issue? And would introduce other, in our opinion more severe issues. See the aforementioned (long and often quite heated) discussions in upstream bugtracker.
(In reply to Egmont Koblinger from comment #7) > I guess a simple > export TMPDIR=/whatever > before starting xfce-terminal (in a wrapper script probably) should do it. That works, although I had a look and this variable will affect all applications run from the terminal. Probably not a good idea! > > And also, wouldn't changing the default TMPDIR from /tmp to /dev/shm solve > > the issue? > > And would introduce other, in our opinion more severe issues. See the > aforementioned (long and often quite heated) discussions in upstream > bugtracker. OK!
(In reply to Teresa e Junior from comment #8) > That works, although I had a look and this variable will affect all > applications run from the terminal. Probably not a good idea! You're right, I haven't thought of it. You might want to undo it from .bashrc or friends, or hack around a bit in xfce-terminal's source.
I made a note of it at https://bugzilla.gnome.org/show_bug.cgi?id=631685#c50
(In reply to Egmont Koblinger from comment #9) > (In reply to Teresa e Junior from comment #8) > > > That works, although I had a look and this variable will affect all > > applications run from the terminal. Probably not a good idea! > > You're right, I haven't thought of it. You might want to undo it from > .bashrc or friends, or hack around a bit in xfce-terminal's source. Actually, if I undo it from .bashrc, the terminal picks TMPDIR's new value and ends up writing to /tmp!
So, can this one be closed?
(In reply to Igor from comment #12) > So, can this one be closed? As far as the gtk3 branch is considered: yes.
(In reply to Egmont Koblinger from comment #13) > (In reply to Igor from comment #12) > > So, can this one be closed? > > As far as the gtk3 branch is considered: yes. Thanks!