Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[rmunn]

If you run Ubuntu Linux and upgrade to the newest version (10.10, "Maverick Meerkat", due to be released in October 2010) you may notice that most of your favorite third-party utilities don't work right. That's because the Ubuntu folks decided that having programs access other programs' memory was a potential security hole (viruses could use this to search for passwords in your Firefox memory, for example), and turned this feature off by default. Just because there aren't many Linux viruses NOW, doesn't mean there won't be any in the future, so their decision makes sense for most people.

However, you aren't "most people" -- you play Dwarf Fortress. And you use utilities that poke around in DF's memory, which means you need to turn this feature back on. How do you do it?

To turn the "let programs poke around in other programs' memory" feature on for your current login session, run the following code snippet at a Linux command prompt:

Code: [Select]

echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

That will work until you reboot the computer, at which point the value will go back to its defaults. If you want to make the change PERMANENT, you'll also need to edit the default value, which is found in the /etc/sysctl.d/10-ptrace.conf file. Edit this file (in super-user mode) with your favorite editor:

Code: [Select]

sudo your-favorite-editor /etc/sysctl.d/10-ptrace.conf
then look for the line:

Code: [Select]

kernel.yama.ptrace_scope = 1
near the end of the file, and change it to:

Code: [Select]

kernel.yama.ptrace_scope = 0

Save, and you're done. Now Dwarf Therapist, dfhack, and your other memory-accessing utilites should be working again.

NOTE: Editing the /etc/sysctl.d/10-ptrace.conf file changes the default value, which is read at startup time. But those files aren't re-read again while Linux is running, so editing that file won't change the ptrace_scope value for your CURRENT login session. To change it for your CURRENT login session, you'll need to run the "echo 0" command above AS WELL. Hope that's clear.

Yes, I know Maverick Meerkat won't be officially released for another couple of months -- but when it does come out, people will be running into this problem. When that happens, point them to this post. (And bump it back up to the first page so people can see it  ).

[sockless]

Aww, now I have to upgrade from 10.04 Lucid. Maybe I'll just uninstall it and install the 32 bit version of Maverick, so I can play DF on Linux.

[finesse]

If you run Ubuntu Linux and upgrade to the newest version... *snip*

Good find rmunn, from the looks of it it can't be done on a per process basis.. not yet anyway, as that would still provide the benefit of the added security. Now we just need to wait for October when this thread isn't on the first page and watch all the qq's

Perhaps the authors of the utils should note it somewhere in their readme's too.

EDIT: so I somehow missed the last sentence of your post, mine seems rather redundant now...

[rmunn]

Short of running the utility as root (which, for the record, is a stupendously BAD IDEA and a worse security hole than turning unrestricted memory-access back on), I can't think of any way to do this on a per-process basis.

Well, there would be one way: parent processes can access the memory of their children under the restrictive set of memory-access rules. So if Dwarf Therapist, Stonesense, etc., came with a feature to launch Dwarf Fortress for you, they would be counted as the "parent process" and could access DF's memory. This would only work for one tool at a time (you couldn't run both Stonesense and Dwarf Therapist and have them both be the "parent" of the DF process, for instance), and would require rewriting each tool's code. Not really worth the effort, IMHO, when a single settings change will restore the working status quo ante.

[Artanis00]

Short of running the utility as root (which, for the record, is a stupendously BAD IDEA and a worse security hole than turning unrestricted memory-access back on), I can't think of any way to do this on a per-process basis.

Well, there would be one way: parent processes can access the memory of their children under the restrictive set of memory-access rules. So if Dwarf Therapist, Stonesense, etc., came with a feature to launch Dwarf Fortress for you, they would be counted as the "parent process" and could access DF's memory. This would only work for one tool at a time (you couldn't run both Stonesense and Dwarf Therapist and have them both be the "parent" of the DF process, for instance), and would require rewriting each tool's code. Not really worth the effort, IMHO, when a single settings change will restore the working status quo ante.

Warning: armchair memory hacking ahead.

Rather than writing each tool to launch DF as a child process, write DFHack to launch DF and then all DFHack based tools should work. Doing this would only make each toolset incompatible (DFHack, Therapist, etc.)

The good news is that this will apply pressure to consolidate under one toolset.

[rmunn]

Now that Ubuntu 10.10 ("Maverick Meerkat") has been officially released, it's time to bump this post to the front page, and keep it there for at least a week or two.

If this thread helped you continue to run Stonesense, or Dwarf Therapist, or any other utility, please say so in the thread. That way as long as it is useful to people, it'll stay bumped to the front page -- but once people stop needing it, it'll drop off the front page again.

[rmunn]

Bumping so that more people can find this thread before they run into problems.

[rmunn]

Time for another bump. Ubuntu 10.10 is still less than a week old, and people who upgrade will need to find this post to make DFHack, Dwarf Therapist, Stonesense, and the rest of their favorite utilities work again after the upgrade.

[zxcvmnb]

Where did you hear about this change? I wanted to find out more but can't find anything much with Google.
Edit: Thank you, rmunn, that's exactly what I was trying to find.

[rmunn]

Where did you hear about this change? I wanted to find out more but can't find anything much with Google.

I started running into errors, so I did a Google search for the error message -- I think my search was for something like "ptrace attach: Operation not permitted" without the quotes. That led me to things like http://blog.mellenthin.de/archives/2010/10/18/gdb-attach-fails-with-ptrace-operation-not-permitted/, which had a link to https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace%20Protection. The Ubuntu wiki also links to some discussions of the problem on the Linux kernel mailing lists. Hopefully that's enough info to get you started on learning more.

[AbuDhabi]

Slightly off-topic: Does the same problem - inability to access the memory of other processes - afflict Debian? I've had this thread pointed out to me when asking in the IRC channel, but using the advice in the first post just returns "No such file/directory/whatever".

[Jake]

Is this going to be applied retroactively to previous versions of Ubuntu?

[Abraxis]

Alright, I have done the temporary fix (for the one session), but Therapist and Stonesense still aren't connecting.  Is it because they're running through wine and I have the Native Linux version of DF 30.16?

Any suggestions?

[Jake]

It certainly won't help, and Stonesense at least is capable of running natively anyway.

[Abraxis]

Okay, I had them all working when I ran all three under wine, Though not so much Stonesense, it was slow and unresponsive.

I just got Dwarf Therapist working natively though, for the native build of DF, here is a link with everything to get it to work http://code.google.com/p/dwarftherapist/wiki/LinuxVersion