Data Breach Flaw Found In Gnome-terminal, Xfce Terminal and Terminator 184
suso writes "A design flaw in the VTE library was published this week. The VTE library provides the terminal widget and manages the scrollback buffer in many popular terminal emulators including gnome-terminal, xfce4-terminal, terminator and guake. Due to this flaw, your scrollback buffer ends up on your /tmp filesystem over time and can be viewed by anyone who gets ahold of your hard drive. Including data passed back through an SSH connection. A demonstration video was also made to make the problem more obvious. Anyone using these terminals or others based on libVTE should be aware of this issue as it even writes data passed back through an SSH connection to your local disk. Instructions are also included for how to properly deal with the leaked data on your hard drive. You are either encouraged to switch terminals and/or start using tmpfs for your /tmp partition until the library is fixed."
Skynet (Score:5, Funny)
We have a means to strike back at Skynet using this breach in the Terminator systems!
Where's the gun? (Score:1)
How is this *really* a problem? (Score:1)
You have to be root (or the user who was running terminal in the first place) to see the scrollback data.
So, how is this different than all of the hack-tastic things that root can already do?
Re:How is this *really* a problem? (Score:5, Informative)
While the system is running, yes, you either need to be root or run an exploit which escalates your privileges so you can see the temp file. When the disk is removed from the system you don't need to be root to read the files. Nor would you need to be root if you booted from a LiveCD.
Re: (Score:3)
When dealing with real security needs, you might want to know if data only seen through SSH end up on your hard-drive.
Umm (Score:4, Interesting)
If someone has physically stolen your computer then the thief being able to read old terminal sessions is the least of your worries.
Re:Umm (Score:4, Insightful)
The problem is your terminal history may include data from other hosts, decrypted. Therefore it's not just "your" worries.
Re: (Score:2)
LUKS. LUKS. LUKS.
Theft of a workstation or laptop drive should not threaten the rest of the network.
Re: (Score:2)
Re: (Score:1)
where is the problem with ssh-keys? mine has a looooooong password.
Re:Umm (Score:5, Informative)
You have to read the bugzilla report carefully to see what this story is about. I'm the developer being [bf]lamed. I offered to find time on a weekend and fix the issue. But the reporter ignored my offer and went ahead to post this on as many places as it could. In the report, he masks that, and instead says I don't consider it a bug. The report is intentionally written misinformed IMO. Which makes me think the true story is that he wanted to get some publicity...
Re:Umm (Score:4, Interesting)
Bug aside, from reading the rest of these threads, it seems to me like GNOME devs are getting quite a bad reputation these days. Sure, there's no way to make everyone happy and I wouldn't expect anyone to undertake this sort of impossible challenge. This being said, all the scorn must come from somewhere. My humble opinion is that once you reach a critical mass of users, enforcing a new grand-vision that the majority of those users (the ones who acutally chose to use GNOME, not those who don't know what a DE is) do not agree with is very likely to cause quite a bit of backlash... Case in point, GNOME developers as a whole being bashed for what essentially is one bug in one lib by one person.
Sure, there's a large portion of users who aren't technical whom one might think they are catering to when they remove features considered 'too complex'. The fact is though that these are the people who don't even care what DE they're using, they're not loyal customers, they're just not interested in what you've done so long as it works for them. The only base GNOME has truly alienated is the base that had made a very conscious and educated choice to use that DE on its technical merits, the ones who felt that the DE allowed them to work the way they want to work. Sure you can change all that but only at the cost of those users. They don't take kindly to what pretty much amounts to: Look, the way you used your computer is stupid, we'll force our alternative on you.
So, as the flames rage on and you feel the burn, remember that the GNOME team doused itself in gasoline prior to this.
Re:Umm (Score:4, Interesting)
I'm a long time GNOME user, not a GNOME developer.
Bug aside, from reading the rest of these threads, it seems to me like GNOME devs are getting quite a bad reputation these days
Nope, they rock. When KDE did there big roll-out of KDE4 the lists *EXPLODED* with the wailing and gnashing of teeth. KDE4 arrived stable and that loud minority either adapted or went on the something else. Much the same thing happened with GNOME3 - although less than I expected. I moved to GNOME3 from GNOME2 and within a week it was clear that it was a superior system. But some adaptation was required.
And this particular bug is nonsense. Basically: if someone steals your harddrive they can read your data! Really? Wow, that's a surprise. This has always been true, is true of /home, /var. and everything else unless you encrypt everything.
This being said, all the scorn must come from somewhere.
Yes, it comes from a vocal minority who don't realize all these changes where discussed and made out-in-the-open. Now they enjoy pitching a fit and claiming the design changes are somehow being forced upon them.
My humble opinion is that once you reach a critical mass of users, enforcing a new grand-vision that the majority of those users (the ones who acutally chose to use GNOME,
Well, I'm one that uses GNOME ~9 hours a day. For work.
GNOME developers as a whole being bashed for what essentially is one bug in one lib by one person.
Eh. Spend time producing ANY kind of content and you'll eventually get someone who thinks they can get themselves some BLOG karma by bashing you.
The only base GNOME has truly alienated is the base that had made a very conscious and educated choice to use that DE on its technical merits, the ones who felt that the DE allowed them to work the way they want to work.
I want to work efficiently. GNOME3 lets me do that... more than GNOME2 did. This is an important distinction from, based on mail list traffic, people who apparently *NEED* to see the real-time weather report for three cities in the panel clock in order to be productive. I think the group primarily 'alienated' by GNOME3 are the "tweakers". They have a computer almost for the sole purpose of tweaking the appearance of the user-interface. One reads much of those posts and says "eh? really? don't you have something to *do*.".
we'll force our alternative on you.
The use of the term "force" in this context is bogus.
remember that the GNOME team doused itself in gasoline prior to this
Nah, they doused themselves with awesome.
GNOME and reality (Score:2)
Nope, they rock. When KDE did there big roll-out of KDE4 the lists *EXPLODED* with the wailing and gnashing of teeth. KDE4 arrived stable and that loud minority either adapted or went on the something else. Much the same thing happened with GNOME3 - although less than I expected. I moved to GNOME3 from GNOME2 and within a week it was clear that it was a superior system. But some adaptation was required.
it's not the same thing. The backlash against KDE4 was because it was released too soon, when it had many bugs and lacked feature parity with KDE3. The backlash against GNOME3 is because it was released at all--because it threw out what has been proven to work in favor of experimental ideas from self-appointed "designers"--because GNOME3, compared to GNOME2, is a developers' and designers' playground. GNOME3 should not have been called GNOME3, because it should not have been intended to replace GNOME2 at
Re: (Score:2)
I agree; this is a case of "nothing to see here, move along.".. Don't let it get to you. GNOME Terminal works great and the scrollback is fantastic. Thank you for your contribution.
Re: (Score:2)
what about terminal-history in your swap-partition?
Re:How is this *really* a problem? (Score:5, Informative)
Now, if you want scrollback data to be persistent across reboots, you have to suck it up and dump it to disk somewhere(user home might be a slightly better idea, since support for encrypting your home directory is slightly easier than for encrypting the entire disk); but if that isn't a requirement you probably don't want it touching the disk at all(unless you are in a very memory constrained and swapless environment where getting OOM killed every time something unexpectedly verbose happens would be really annoying).
Re: (Score:2)
...'root' is anybody who mounts the HDD......
IF someone has your HD then what's in /tmp is the least of your problems if you have secrets to hide.
Re:How is this *really* a problem? (Score:5, Informative)
It's a particular problem if you A) don't run on entirely encrypted partitions, and B) have your kit stolen or get rooted. Your biggest problem is that you had your kit stolen or got rooted, however, this problem effects the damage control process.
Usually when you have a compromise you assume that only data that is "on the host" is compromised, and any data from other hosts is only compromised if it happened to be viewed after you got rooted (because the attacker could have been keylogging.) With cleartext from encrypted sessions hitting disk, this means that data could be sitting around in unused block in /tmp for years, so once you get rooted you have to assume everything ever done on other machines using a terminal on that machine has been exposed. So if you edited your corporate HQ's VPN PSK 2 years ago, that may still be on your disk.
tmp is less likely to be on an encrypted media than other filesystems, because it is usually expected to be a performance bottleneck.
The good news is that in many cases the data never got flushed back to disk and stayed in the filesystem buffers, but for high security concerns this is little consolation.
Re: (Score:3)
Very much in agreement, but in some instances there are additional features that further mitigate this at least in the long-term.
With cleartext from encrypted sessions hitting disk, this means that data could be sitting around in unused block in /tmp for years, so once you get rooted you have to assume everything ever done on other machines using a terminal on that machine has been exposed.
One piece of good news is that some systems erase /tmp on startup. Debian does this, for one. But also last I knew, other systems don't. Someone had reported about a year ago that Fedora didn't do this, for instance. It came up because the poor guy was using a Debian-based box and had copied his entire home directory into /tmp, rebooted, and expected to copy it back. Oops. T
Re: (Score:3)
One piece of good news is that some systems erase /tmp on startup. Debian does this, for one.
Yes and no... Debian (and most other systems, I might add) only deletes the files/dirs that are still present on the filesystem (i.e. what "find" can find on /tmp). It doesn't try to securely wipe those data blocks or the data blocks that wasn't part of any of those files.
Damn good point. I stand corrected.
The last part is important, cause in the case of libvte, the file is open()'ed, then unlink()'ed right away, thereby no longer showing up on the filesystem even though the file is still in-use. The close() won't happen until the terminal is closed. In other words: As the file is no longer present on the filesystem, it won't be deleted (again) from /tmp and the data blocks won't be wipe. Therefore the old data will still be present on the disk even after a reboot.
I think you're right. :-/
You could probably change the boot script to use a more secure wipe of the files it's deleting, but that still won't help you in this case as the file in question was already delete long before the reboot. A complete wipe of /tmp's device won't be a good idea either, unless you're absolutely sure /tmp is on its own device, i.e. if /tmp is just an ordinary dir on /, you don't want to wipe all of / on boot up.
I suppose one option would be a "secure wipe on free space" via the sfill command from the secure-delete package on the filesystem that /tmp is mounted on.
IIRC at some point certain filesystems had a flag to set for a "secure delete" option, which would fill files erased with zeros when a file link count reached zero, but I don't recall whether any of these were actually implemented.
Aterm (Score:2)
Aterm seems to be ok.
i don't see it listed as using libVTE
http://packages.debian.org/wheezy/aterm [debian.org]
Re: (Score:2)
Doesn't sound like a flaw to me (Score:1)
This really sounds like how it was designed to work.
Thats what /tmp is for, after all, is it not? Sounds like the problem would be solved by partitioning different users data into seperate, appropriately secured /tmp files.
Is bash history a "flaw" too? I'm sure plenty of people don't know that it's a text file anybody with access to it can read.
Re: (Score:2)
This really sounds like how it was designed to work.
Thats what /tmp is for, after all, is it not? Sounds like the problem would be solved by partitioning different users data into seperate, appropriately secured /tmp files.
Is bash history a "flaw" too? I'm sure plenty of people don't know that it's a text file anybody with access to it can read.
Bash history is a different kind of threat; it's only about what command you used. Sure, you could get a few hostnames from it, but no more. /tmp is backed by the harddrive.
Having your terminal session stored on disk mean that everything you see is suddenly on your filesystem, and staying on it if your
Re: (Score:1)
Some people execute commands that take a password as a command line argument.
Besides even that, you can learn a lot about a person from their .bash_history. More than just a few hostnames. You can make some inferences at least.
Re: (Score:2)
No. If you open(O_CREAT) a file than immediately unlink it, and use the opened handle to store temporary data, that data has no more chance to hit the disk than regular memory being swapped out.
Try to learn a bit about buffer cache and such stuff.
This "bug" is about someone ignorant about security and how an OS works having his naive assumptions contradicted by reality.
So, the fact that it does work with the current implementation of some terminal emulator doesn't count as reality?
I didn't say that there is no good way to do this correctly...
Re: (Score:2)
dd if=/dev/zero of=disk.img bs=1M count=5
/sbin/mkfs -F -t ext2 disk.img
sudo mount -o loop disk.img
sudo chmod a+rw
python -c 'import os; f = os.open("/mnt/a", os.O_CREAT | os.O_RDWR); os.unlink("/mnt/a"); os.write(f, "Hello world"); os.system("sync");';
strings disk.img
sudo umount
rm disk.img
seems to reliably find "Hello world" from the disk.img every time.
Re: (Score:2)
Re: (Score:2)
What filesystems do you use that are never synced?
Re: (Score:2)
I don't follow you. It's not about trashing the cache, it's about syncing. ext3 and ext4, for example, sync every 5 seconds by default.
I really don't follow your second paragraph--it seems to contradict your point in the first. Now you seem to be saying, "Yes, indeed this terminal scrollback file will be written to disk." And that's the whole point: we don't want it to hit the disk.
Even without syncing, manually or automatically, I routinely run low on RAM, my caches shrink, and stuff gets swapped. And
Re:Doesn't sound like a flaw to me (Score:4, Insightful)
People in the know know about cli history files. They don't necessarily expect data viewed in a terminal window to hit disk. It may or may not be a "flaw" depending on your opinion as to what appropriate security measures amount to, but it's worth an awareness campaign.
tmpfs (Score:5, Insightful)
Once you go tmpfs, why would you ever go back, VTE flaws or not? tmpfs kicks ass.
Then encrypt your swap (random key every boot; you don't even need to know a key to be coerced from you) and you have a safe /tmp.
Re: (Score:2)
Re: (Score:2)
Then set up a keyfile for swap and edit /etc/crypttab appropriately. If you're doing the rest right, your encrypted root will protect the swap then, as well - yet you can comply with law enforcement and hand over the keys if ordered., yet still helps protect you from the thieves and other asswipes.
Re:tmpfs (Score:5, Informative)
In some countries, it is illegal for you not to divulge the key to properly warranted authorities - even if you don't know what it is.
So what? In my country blasphemy is illegal. I'm not from the Middle East either, I'm a Finn. - Sometimes you just have to, grow a backbone, fuck Jesus in the ass and break the law.
Re: (Score:1)
On a memory-limited system, one may not want /tmp kept as tmpfs in the RAM.
Re: (Score:1)
Re: (Score:2)
My N900 with only a quarter-gig RAM uses tmpfs and it doesn't cause any trouble.
Re: (Score:1)
Encrypt swap? Who the hell uses swap these days?
Lets says you have a mere 4GB of RAM. A small swap file of say 512MB would be useless considering how much you already have but if you go to 1GB+ size swap files then your machine is going to grind to a halt (ie. become useless) if you start swapping that much memory.
Swap is useless and/or pointless if you have 2GB or more of RAM.
Re: (Score:1)
why? When processes get bigger and harddrives get faster, the swapfiles can grow as well.
Re: (Score:3)
Swap files may grow, but the speed of hard drives doesn't scale along with everything else. Take a good platter-based drive and you're lucky to see reads/writes of 20MB/s assuming little to no HDD contention, especially since swap is typically highly random non-sequential 4k access. RAID that up or us an SSD and you might get 50MB/s. Lets say you have a 512MB swap, as I do, it'll take 10s to read the whole thing. Take a 512GB swap (like one poor server I found at work - someone was following the appallingly
Re: (Score:2)
> Stick with a small swap file and not much crap ever gets written to disc, saving you the horror of having to reset a server for the umpteenth time when it's been grinding on its system disc for five minutes trying to page in the OOM killer.
Great theory, but in reality it would hit the OOMk too often and random processes would die too often. Hey, I've suffered swap-of-doom plenty of times, so I know what you mean and feel the pain--but the alternative is worse.
What really does help is zramswap. Makes
Re: (Score:2)
Not in my case. I would MUCH rather my machine kill a huge memory-hog process rather than let my 8GB desktop machine thrash and die. If a process is going to start swapping, then it will take FOREVER to finish. I would rather have it die. That way, I can tell what is happening and still control my computer. Then, I can throw the job on one of grid machines with 64GB a
Re: (Score:3)
*Sigh*, this again. No matter how much memory you have, some of it will end up with accumulated cruft that rarely needs to be read/changed. That ram would be better used freed up (swapped out) and used for cache instead. And 2 GB is nothing compared to a modern Desktop (gnome, Unity, KDE, take your pic.) If you do any kind of multitaking of large applications, you need a minimum of 8GB before you can be safely swap free.
Re: (Score:1)
Re: (Score:2)
It fits at first--but after a day or two it doesn't. Then you have to restart X, or at least log out/in.
Re: (Score:2)
Do you even run X? I have systems with 3 and 4 GB of RAM and they still end up sucking up more and more RAM and swapping stuff out if I have a long enough X session and use a modern web browser. If I had 2 GB and no swap I'd hit the OOM killer every few days at least.
Re: (Score:2)
Swapping to read files from tmpfs is going to grind slower than using a disk filesystem for /tmp? I guess it's time to do some benchmarks because if it's true, I'd call that a tmpfs bug.
People are telling me don't use disk because it's too slow, but don't use ramdisks because their computer doesn't have enough RAM. The only thing people can agree on, is that I'm wrong.
Re: (Score:2)
"(you don't even need to know a key to be coerced from you)"
Great. That just means a longer beating from the proverbial XKCD Crescent wrench....
Re: (Score:2)
I shall look but you seem to know how to setup and configure to use tmpfs for /tmp. I'm using LXDE and they use tmpfs for some things but I'm unsure if /tmp exists there. Thanks.
Cheers, Behdad Esfahbod, nice one (Score:1)
Interesting choice of inspirational quote:
The same applies to blame, Behdad.
Not a bug (Score:5, Insightful)
This is not a bug. This is exactly how /tmp is meant to be used. It is no different from sensitive data from your internet cache being stored on the hard drive.
If your garbage data is sensitive, you should encrypt /tmp, or mount a tmpfs there.
Re: (Score:1)
Re: (Score:2)
There is a big difference between bug and flaw.
*rimshot*
hello, this occurs with swap too (Score:3, Informative)
This is true of vi and many other programs. The exact same issue occurs with the swap partition.
Anyone can solve this problem, just mount /tmp and swap using dm-crypt with a new random password every reboot. The partitions are perfectly good while the computer is booted, but are inintelligible afterwards.
Re: (Score:2)
Of course, I also close firefox every day - it leaks memory.
Is konsole affected? (Score:2)
Well?
Re:Is konsole affected? (Score:4, Informative)
I haven't had time to look into it completely, but when you have konsole set to unlimited scrollback mode, it will create files in /tmp/kde-username/konsole*.tmp that have your scrollback buffer. It is encoded somehow, but its there. I'm not sure if its encrypted or not. I found out about it because when I talked with the libvte developer (Behdad), he said that he looked at the code in Konsole to see how they did it before writing the implementation in libvte.
Re: (Score:2)
Note: I do not recommend konsole because it has the same issue with writing scrollback buffer to disk. It encodes the data so it is not as visible, but it would be trivial to decode that data.
Re: (Score:2)
It looks like only if the scrollback size is unlimited or at least really huge. /tmp.
I have 1000 line scroll back and konsole creates no such files in
My hard drive ... (Score:2)
Aside from that, any /tmp (physical or volatile) can be a problem on a multiuser system if the app is dumb enough to create files with go+r permissions. If this isn't done, those files are as secure as any in my home directory.
Who doesn't have /tmp as a tmpfs at this point? (Score:4, Interesting)
Re: (Score:2)
With all the layers of caching between an application and the spinning drive, isn't /tmp (and every other filesystem) essentially in-memory anyway (at least for short-lived files)?
Re: (Score:1)
No. This is one of the more common misconceptions.
tmpfs is an entire filesystem in memory. It stores objects directly in memory. It is MUCH MUCH faster than a regular filesystem because its metadata keeping is much cleaner, simpler, and it is hot-cache-aware. This is speedup 1.
tmpfs does not have a backing store device other than swap, while a normal filesystem does. A normal filesystem HAS to evict dirty pages and metadata to the backing store, even if you created and destroyed a file before the write
Re: (Score:2)
I benchmarked this about a year ago on a couple RHEL5 servers. A particular application wrote out a few MBytes of tmp files everytime the application was asked to sort some data... which was so often we were talking hundreds of megabytes... vastly more IO than /tmp on a normal system would ever see.
Anyhow, long story short, moving /tmp to tmpfs (RAM) made absolutely no performance improvement at all. In fact it was a small slowdown... I assumed this was because it was pushing some buffers/cache out of p
How is this is this different to shell history? (Score:4, Insightful)
Various shells store command history as a .[shell name]_history file in the users home directory which can be left between sessions. Thats happened for years and root can view that too.
Sure, this may be a bug but frankly its a non issue.
Re: (Score:1)
Shell history doesn't contains only input, not output.
Someone may have splashed some GPG private keys to the terminal, and the output ends up in the filesystem blocks.
Re: (Score:3)
Re: (Score:2)
Various shells store command history as a .[shell name]_history file in the users home directory which can be left between sessions. Thats happened for years and root can view that too.
Sure, this may be a bug but frankly its a non issue.
It might not be a high risk issue, but it probably should still be fixed.
Re: (Score:2)
I think the slashdot bragging rights were more interesting to him. :)
What an arrogant prick you really are. He replied to your suggestions telling you that they weren't helpful, and that you should just rip the code out. He was right. Your response? You told him to fork VTE!!!! Seriously? A shining example of free-software, this is not.
Nothing to see here ... (Score:1)
What about Konsole? (Score:2)
Does this impact KDE's Konsole, too?
Re: (Score:1)
Re: (Score:2)
Yeah, I saw that after I posted,
XTerm FTW! (Score:1)
Re: (Score:1)
I'd be a little miffed (Score:5, Insightful)
If I were the author of this library I'd be a little annoyed. The article is written as if the library does something wrong. It does not. It stores data on /tmp, which is there to be used as scratch space. To read the file you have to be the owner or root, which has been true of every process that has written there since before my years. This is perfect correct.
Okay some uses might not expected their terminal emulator to keep temporary files. Yes if your disk is appropriated someone not root in your environment might be able to read it. Which is true of basically any process that writes anything to disk anywhere; even ones that don't. Suppose my system is under enough VM pressure that my good old fashion xterm gets paged out? Why scroll back buffer data, which might even have come from SSH would be right there on my disk! OH! NOS!
If you are dealing with a system that is physically insecure, like a laptop, or machine in a public spot, or information that is so sensitive you'd be more concerned about it being out there than the fact that your hard disk or entire system has gone missing; there is a solution for that. Its called disk encryption! If you use Linux it won't even cost you anything!
Re: (Score:1)
See my other comment also:
http://linux.slashdot.org/comments.pl?sid=2714201&cid=39291633 [slashdot.org]
Scrollback is for noobs (Score:2)
If an attacker is reading plaintext off a drive... (Score:2)
AES-NI makes encryption almost free. There's no reason not to use it.
Ever heard of swap? (Score:2)
This is truly a non-issue. If your machine has swap, then ANYTHING in memory can end up on the disk. The data is not exposed in a way that it can be grabbed by other users, you would have to dig through the disk image to find the unlinked file.
Very simply, if you ever dispose of or sell a hard drive, you MUST wipe it first. If a drive fails and you want to make sure no data gets out when you throw it away, you must destroy the platters.
SSH has nothing to do with this. It is not and never was a magic faery w
VT100 (Score:3)
Yet another reason to use a VT100 hooked up to the serial port !
I fixed it for you (Score:2)
Re: (Score:1)
The sky is blue! The sky is blue! (Score:2)
This is how you should implement unlimited scrollback, create a tmp file in /tmp and then unlink it so it will be freed on exit.
Re: (Score:2)
He is mounting "/dev/sdb1" to "/tmp". Most Linux systems mount the in-memory only "tmpfs" to "/tmp", so data written to it is in memory only. Unless the pages comprising "tmpfs" are swapped to disk, none of this information should ever even touch the hard disk. But the way he set it up, "/dev/sdb1" will capture all terminal data. Why would you even set it up this way to begin with? It's not the default setup.
This is pretty stupid. Not a security vunerability, just another thing to be careful of -- never mou
Re: (Score:2)
These claims are actually not true. Results that show otherwise forthcoming.
Violating established conventions without warning (Score:2)
The point is that this data should never have hit the disk in the first place. The screen is expected to be an ephemeral medium--not one recorded to disk automatically. How would you feel if you discovered that ffmpeg was recording your entire screen to /tmp/username.mpg without your knowledge? Sure, clear your browser cache and history and vacuum the dbs--but then all I need to do is find the stream of your desktop session video and play it back, and I'll be able to see most of what you did, even though
Re: (Score:1)
You got that half right.
Re: (Score:2)
You're just saying that because you don't read climagic [twitter.com]
Overblown (Score:5, Insightful)
That would be in your .bash_history file (or whatever you name it locally).
Really, this is way overblown by calling it a "data breach": it's not as if your data is compromised to a remote attacker. It requires that somebody else has your disk. As we all know, if your hardware is stolen/confiscated/impounded/seized/whatever, only encryption can keep your data safe. Apparently, even that can be circumvented by legal compulsion.
Re: (Score:3)
Re:Overblown (Score:5, Informative)
That's misinformed. Vte creates files in /tmp, and immediately delete them. So, the space will be reclaimed as soon as the terminal tab in question is closed. I know this is how it works, because that's how I wrote it.
Re: (Score:2, Insightful)
So on a running system (using LUKS or not), any user that has read-permissions on the block device (members of i.e. group disk) containing /tmp will be able to see all other user's input? how sweet! And why delete them? A process that uses a file to write data, will keep using this space until closed anyway, so you might as well just show they're actually there taking up space? Or is there something in these files that isn't supposed to be easily seen? oh wait.
This is not only a risk for offline filesystems
Re: (Score:2)
Re: (Score:1)
Re: (Score:3)
Yes, temp data is written to /tmp/
Indeed. And everything created in /tmp also has drwx------ permissions (by default on all of my systems). So even with several users simultaneously logged-in, the files of one user in /tmp are not accessible to other logged-in users except those with root privileges, and they can access almost anything anyway, if they want to.
Which is not to say it couldn't be done better, so that it would not be available to others - not even root, and not even if the disk were stolen. Suggestions for this include havin
Re: (Score:2)
Yes, it's overblown, but tmpfs is not a reliable solution. If the system is under heavy enough load and memory pressure, the tmpfs contents may get swapped out to disk anyway.
And oh yeah, the swap partition on your disk is a liability too. But anytime someone has physical access to your disk, all bets are off anyway...
Re:Yet another reason to switch to KDE permanently (Score:4, Informative)
Anonymous Coward,
You may want to read the end of this comment before jumping to conclusions:
https://bugzilla.gnome.org/show_bug.cgi?id=664611#c10 [gnome.org]
Ie. I offered to fix it, before the report was published. And the report is deliberately misinformed to make it look like I said I don't have any intention to fix it. And the report author tweetted [1] "Apparently not a lot of people read Slashdot anymore or RTFA. I've only had 971 hits to the article so far. :-(", which makes me believe that his true intention was to get Slashdot / Reddit / Hacker News bragging rights. Comes handy if you are a sysadmin I guess...
behdad
[1] https://twitter.com/#!/climagic/status/177796284755873793 [twitter.com]