The forum

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

Hi,
I don't think there's "moutains of scripts" doing this check already, but you probably met it often if you're playing recent games because it was added to the script that installs .NET 3.0 (POL_Function_dotnet30). Some games were already known to require ptrace to run, so it may not be the only one.
I agree that some research could be done to handle this problem better, from both security and ergonomy point of view, and already mentionned capabilities in this very forum.

Problems are:
- I don't know what ptrace is needed for exactly. I don't play recent games, so I've yet to use a program that requires it, and I don't know what are the symptoms on .NET 3.0 installation if ptrace is not available;
- using capabilities on some wineserver and/or loader has its own security implications: I assume all Windows programs started using this will get ptrace access. Maybe that could be mitigated by having a specific Wine version to put this capability on
So everyone is welcome to experiment and give answers to the questions raised.

We have talked about this problem in another thread too: dotnet
We have not found a resolution, but I went ahead and deleted dotnet30 from my resources folder and re-downloaded the packages again.

I havn't seen it since.

No, we have not "talking about this problem in another thread", please reread PatriotBob suggestion so you can contribute in a meaningful way.

For those who never heard of capabilities, the manpage:
http://swoolley.org/man.cgi/7/capabilities

(any additional resources on the topic welcome)

Edited by petch

if [ -e "/proc/sys/kernel/yama/ptrace_scope" ]; then
        PTRACE_CHECK=`cat /proc/sys/kernel/yama/ptrace_scope`
        if [ "$PTRACE_CHECK" != 0 ]; then
                POL_Debug_message "$(eval_gettext 'The game will fail to launch until you set /proc/sys/kernel/yama/ptrace_scope to 0')" "$TITLE"
        fi
fi

Edited by PatriotBob

I just wrote this: http://www.playonmac.com/en/source-1690-POL_Test_ptrace.html
It's untested, mostly there for comments for the moment.

# Check Kernel ptrace

# Without Yama patch, we assume ptrace is allowed from anywhere
if [ -e "/proc/sys/kernel/yama/ptrace_scope" ]; then
        NEED_WINESERVER_RESTART=''
        while true; do
                [ "$(cat /proc/sys/kernel/yama/ptrace_scope)" = 0 ] && break
                if setcap -q -v cap_sys_ptrace=ep "$(which wineserver)" then
                        [ -n "$NEED_WINESERVER_RESTART" ] && wineserver -k
                        break
                fi
                NEED_WINESERVER_RESTART=1

                POL_SetupWindow_menu_num "$(eval_gettext 'The program needs access to ptrace() to proceed:')" "$TITLE" "$(eval_gettext 'Give the capability to wineserver executable')~$(eval_gettext 'Enable ptrace() globally')~$(eval_gettext 'I fixed it myself, just retest')~$(eval_gettext 'Abort installation')" "~"
                case "$APP_ANSWER" in
                    0)
                        POL_Call POL_Function_RootCommand 'sudo setcap cap_sys_ptrace=ep "'"$(which wineserver)"'"'
                        ;;
                    1)
                        POL_Call POL_Function_RootCommand 'echo 0|sudo tee "/proc/sys/kernel/yama/ptrace_scope"'
                        ;;
                    2)
                        ;;
                    *)
                        NOBUGREPORT="TRUE"
                        POL_Debug_Fatal "$(eval_gettext 'User abort')"
                        ;;
                esac
        done
fi

From reliability point of view, I'd prefer to test if the capability is available by running a small Windows program that exercises the API that require ptrace(), but that's totally out of my league ;)

Edited by petch

When you do a manual installation, there is a package called: POL_Test_Ptrace

Does anyone know anything about that?

Yes, it contains the same code as above. It's unused since there has been no feedback about that suggestion.

Ok, I'll have to try it next time I install dotnet
Thanks

The script in the repo actually has bad syntax in it somewhere, but as Im new to this type of stuff (dev), Im not sure where to look. It fails, though. When I run the commands by themselves (the root ones), it works great.

Is this script reboot-proof?

If you mean just a wineserver reboot, then I didnt need it, though I just copied the sudo commands and did it by hand, as I cannot figure out what is the syntax error in it. There is one on line 11 where a "fi" is, but Im not sure if its indentation thats causing it or what. I have to assume indentation, as its python/bash for the scripts, correct?

That was a missing semicolomn, line 8 (between the test and the "then";

@Quentin: I'm not sure what you mean by reboot-proof. If you mean, does this script make persistent system changes, the answer is no if the user chooses ptrace_scope, it should be yes if the user chooses setcap.
On the other hand, recent experiments seem to show capabilities are more complex than we thought, and it probably doesn't work as-is.

I still get an error when I use. Line 4, closing quote. Im actually trying to debug it right now. I need the practice. :)

Fixed it. :)

Works fine now. Menus and all.

Here are the changes that I made. The window opens up just fine, and all of the options work as expected for the most part. It actually closes now, too. This could turn out to be handy.

#!/bin/bash
 
#  Check Kernel ptrace
 
#  Without Yama patch, we assume ptrace is allowed from anywhere
if [ -e /proc/sys/kernel/yama/ptrace_scope ]; then
        NEED_WINESERVER_RESTART=''
        while true;
            do [ "$(cat /proc/sys/kernel/yama/ptrace_scope)" = 0 ] && break
                if setcap -q -v cap_sys_ptrace=ep "$(which wineserver)"; then
                        [ -n "$NEED_WINESERVER_RESTART" ] && wineserver -k
                        break
                fi
                NEED_WINESERVER_RESTART=1
                POL_SetupWindow_Init
                POL_SetupWindow_menu_num "$(eval_gettext 'The program needs access to ptrace() to proceed:')" "$TITLE" "$(eval_gettext 'Give the capability to wineserver executable')~$(eval_gettext 'Enable ptrace() globally')~$(eval_gettext 'I fixed it myself, just retest')~$(eval_gettext 'Abort installation')" "~"
                case "$APP_ANSWER" in
                    0)
                        POL_Call POL_Function_RootCommand 'sudo setcap cap_sys_ptrace=ep "'"$(which wineserver)"'"'
                        ;;
                    1)
                        POL_Call POL_Function_RootCommand 'echo 0|sudo tee "/proc/sys/kernel/yama/ptrace_scope"'
                        ;;
                    2)
                        ;;
                    *)
                        NOBUGREPORT="TRUE"
                        POL_Debug_Fatal "$(eval_gettext 'User abort')"
                        ;;
                esac
        done
fi
 
POL_SetupWindow_Close
exit 0

(Please don't use this into PlayOnLinux scripts for the moment)

If the user make the first choice, it will work until the next reboot, and then he will have troubles.

That's why it's not a good solution for me

Yeah. I wasn't going to add it into anything, as its just experimental. I just wanted to see if I could debug it. :-)

I know this is an ancient thread, but it seems to be the only discussion of the ptrace_scope issue. I've run into this recently while installing a game, and am really hesitant to set ptrace_scope to 0 system-wide; it's a legitimate (and relatively important) security constraint in modern kernels, and it's why the capabilities subsystem exists.

I've been playing around with POL_Install_dotnet30 ( https://www.playonlinux.com/en/app-563-POL_Install_dotnet30.html ) and setcap a bit, as well as looking at POL_Test_ptrace ( https://www.playonlinux.com/en/source-1690-POL_Test_ptrace.html ) which is much closer to what I'd like.

I was wondering:

1. Is there a reason why adding setcap support hasn't had any movement in the last 3 years?
2. Is there an easier way to test changes to a local version of scripts (i.e. POL_Install_dotnet30) than chattr +i'ing the version in tmp/? (broken fingers and all that)
3. Does anyone know what the actual need for ptrace is? I've removed the ptrace_scope check from POL_Install_dotnet30 on my local machine (which has ptrace_scope set to 1) and tried installing the first small supported application I found that needs it (OBDwiz - https://www.playonlinux.com/en/app-2645-OBDwiz_OBDII_vehicle_diagnostic_program.html ), but installing dotnet30 and the software itself worked fine...
4. Is there somewhere I can see all of the POL_Install_* scripts? I know POL itself downloads them from the website, and I can find the source of individual ones. But is there a git repository backing this or something, or are they just maintained in whatever runs the website?