setting ptrace_scope to 0 on WSL 2

[MisterAero]

1.Do I have to do this step (What will I lost if I don't)?

2. What are the alternatives? ( The only file on WSL2 that refers to this setting is: etc/sysctl.d/10-ptrace.conf:22:kernel.yama.ptrace_scope = 1 , but it is never being read/referenced elsewhere I think this is still an open issue for WSL 2.

From Frida installation page:

If you are on GNU/Linux, issue:
$ sudo sysctl kernel.yama.ptrace_scope=0
to enable ptracing non-child processes.

sysctl: cannot stat /proc/sys/kernel/yama/ptrace_scope: No such file or directory

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

/proc/sys/kernel/yama/ptrace_scope: No such file or directory

From

The sysctl settings (writable only with CAP_SYS_PTRACE) are:

0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other process running under the same uid, as long as it is dumpable (i.e. did not transition uids, start privileged, or have called prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is unchanged.

1 - restricted ptrace: a process must have a predefined relationship with the inferior it wants to call PTRACE_ATTACH on. By default, this relationship is that of only its descendants when the above classic criteria is also met. To change the relationship, an inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare an allowed debugger PID to call PTRACE_ATTACH on the inferior. Using PTRACE_TRACEME is unchanged.

[songku]

I was using another program that require this ptrace_scope setting and I noticed that WSL2 ubuntu kernel did not contain yama module which is unable to be installed based on WSL2. Therefore,I think you'd better try a more complete linux in VMware or linux container in Docker.