Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

To run certain Windows programs in WINE you need to this workaround:

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

According to the support websites, this is due to a bug in the Ubuntu kernel that prevents ptrace and WINE playing well together.

Using the above command you set the ptrace to 0 which according the research I've done(don't ask me which websites, I have seem a lot of them), ptrace has to do with the interactions between programs. The 0 setting is more permissive than the 1.

I have to assume that there was a good reason Ubuntu wanted the ptrace=1 so this leads me back to the short form of the question.

Are there any risks involved in setting ptrace=0. Lower security? problems debugging? any others that I haven't thought of???

P.S. for anybody reading this that wonders what the bug causes, the Windows programs will fail to open at all, in the System Monitor you will see many instances of the program trying to open and then they will eventually all quit and if you run the progam for the terminal you will get an error that tells you that the maximum number of program instances has been reached.

share|improve this question
Here is a description linked from a PlayOnLinux pop-up error message which aborts installation of .Net 4.5 unless the ptrace_scope is set to 0:… – pabouk Oct 26 '15 at 19:23
up vote 24 down vote accepted

Short answer: no practical danger yet, but read on for a better way...

What's this ptrace thing anyway?

this is due to a bug in the Ubuntu kernel that prevents ptrace and WINE playing well together.

  • No, ptrace protection is a deliberate kernel security measure first introduced around Ubuntu 10.10. It's not a bug, and so isn't going to be "fixed".

  • In simple terms, the default ptrace_scope value of 1 blocks one process from examining and modifying another process unless the second process (child) was started by the first process (parent).

  • This can cause problems with some programs under Wine because of the way wineserver provides "Windows Services" to these programs.

What are the risks in setting ptrace_scope to 0?

  • This restores the old behavior where one process can "trace" another process, even if there is no parent-child relationship.

  • In theory, a piece of malware can use this to harm you/your computer; e.g. it can attach to Firefox and log all of your URLs/passwords, etc. In practice this is extremely unlikely unless you blindly install binary debs from random sites, etc.

  • As far as debugging goes, the 0 settings is in fact required for gdb, strace, etc. to attach to non-children unless you run them with elevated privileges (sudo).

What are the problems with the workaround?

  • The workaround is somewhat problematic because ptrace_scope is a global value, and while it's set to 0, all processes on your system are exempt from the non-child restriction.
  • If you use the workaround, put it in a simple bash script that enables it, runs your Windows program and then disables (sets to 1) on exit.
    • DO NOT make ptrace_scope world-writable (666) as the forum post recommends -- that is a huge security risk because now any process can change it at will!

Is there a better solution?

  • A better solution which is more secure and does not require repetitively modifying ptrace_scope is to grant Wineserver ptrace capabilities.

    • In a terminal:

      sudo apt-get install libcap2-bin 
      sudo setcap cap_sys_ptrace=eip /usr/bin/wineserver
      sudo setcap cap_sys_ptrace=eip /usr/bin/wine-preloader
    • This exempts the wineserver and wine-preloader binaries from the non-child ptrace restriction, and allows them to ptrace any process.

    • It only needs to be done once, and is safer because these binaries are usually from a trusted source - the official repositories or the official Wine PPA, so they aren't going to be malware.

If you're using Crossover

Install libcap2:

sudo apt-get install libcap2-bin;

Then, add an exception for Crossover:

sudo setcap cap_sys_ptrace=eip /opt/cxoffice/bin/wineserver;
sudo setcap cap_sys_ptrace=eip /opt/cxoffice/bin/wine-preloader;

Finally, add its libraries to (or you will get "error while loading shared libraries: cannot open shared object file: No such file or directory"):

echo /opt/cxoffice/lib/ | sudo tee /etc/
sudo /sbin/ldconfig
share|improve this answer
I think it is being called a bug because ptrace was working fine in 10.10 after Wine was patched to support it. It has been working with 10.10-11.10 but has regressed in 12.04. – TrailRider Jun 23 '12 at 15:32
Thanks for the accept @TrailRider; I was referring to your statement that "it's a bug in the kernel" (which it's not); it's is certainly a bug-of-sorts for Wine, and should get swatted :) Things certainly change in the kernel sometimes, usually for the better, and it's left up to software that's affected to fix itself rather than tell Linus "yo man, go revert yourself" :P – izx Jun 28 '12 at 5:11
I understand what you are saying here and agree, I only said it was a bug in the kernel as several support websites as well as Codeweavers called it a kernel bug. Here is codeweavers page on it. – TrailRider Jun 28 '12 at 20:41
I was setting the global ptrace to 0, and back to 1 after a few seconds the application starts; setcap is MUCH safer and not annoying as having to sudo all the time.. thx vm! – Aquarius Power Jul 1 '13 at 2:24
@izx: Thanks for this answer. It would be interesting to add information about what "eip" refers to (explained here: Additionally, I have suggested recommending this method in the reptyr docs, where the author replied that it may be a security issue: - it would be great, if you could elaborate on that. – blueyed Dec 1 '13 at 7:20

In the I got an answer with the following link

here is the paste from the link(with my emphasis added)

As Linux grows in popularity, it will become a growing target for malware. One particularly troubling weakness of the Linux process interfaces is that a single user is able to examine the memory and running state of any of their processes. For example, if one application (e.g. firefox) was compromised, it would be possible for an attacker to attach to other running processes (e.g. gpg-agent) to extract additional credentials and continue to expand the scope of their attack.

This is not a theoretical problem. SSH session hijacking and even arbitrary code injection is fully possible if ptrace is allowed normally.

For a solution, some applications use prctl() to specifically disallow such ptrace attachment (e.g. ssh-agent). A more general solution is to only allow ptrace directly from a parent to a child process (i.e. direct gdb and strace still work), or as the root user (i.e. gdb BIN PID, and strace -p PID still work as root).

This behavior is controlled via the /proc/sys/kernel/yama/ptrace_scope sysctl value. The default is "1" to block non-child ptrace. A value of "0" restores the prior more permissive behavior, which may be more appropriate for some development systems and servers with only admin accounts. Using "sudo" can also grant temporarily ptrace permissions via the CAP_SYS_PTRACE capability, though this method allows the ptrace of any process.

So I guess the short answer would be that it's less secure but the likely hood of a personal computer coming under those kinds of attacks would be pretty slim.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.