The forum

Setting ptrace_scope to 0

Can we stop requiring this?

Author Replies
PatriotBob Tuesday 7 May 2013 at 2:40
PatriotBobAnonymous

There's a good reason ptrace_scope is set to 1 and requiring that it be set to 0 is a bit much.

I'm noticing in a few of the scripts (Skyrim - Steam method) that would require that /proc/sys/kernel/yama/ptrace_scope be set to 0. The prefered method would be to use setcap to give wineserver and wine-preloader access to ptrace. Could we maybe start checking getcap for wineserver/wine-preloader?

If there's a reason this won't work, please let me know. If it will, how would I go about making the change. (I'm sure there's a mountain of scripts just checking `cat /proc/sys/kernel/yama/ptrace_scope`)
Ronin DUSETTE Tuesday 7 May 2013 at 3:01
Ronin DUSETTE

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

Please:
Post debug logs & full computer specs in first post
No private messages for general help, use the forums
Read the wiki, Report broken scripts
petch Tuesday 7 May 2013 at 11:24
petch

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.
booman Thursday 9 May 2013 at 21:14
booman

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.

† Booman †
Mint 21 64-bit | Nvidia 515| GeForce GTX 1650
Linux for Beginners | PlayOnLinux Guides | PlayOnLinux Explained
petch Thursday 9 May 2013 at 21:32
petch

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

PatriotBob Saturday 11 May 2013 at 0:40
PatriotBobAnonymous

I understand where you're coming from petch. I wasn't sure why ptrace was needed, but setting it globally didn't sound like a good idea. While I don't like the idea of allowing ptrace on winserver/loader because of the implications you mentioned, I find it much more better than the alternative. (Enabling it globally).

At this point as I don't have a better solution to the problem as a whole, the only thing I would be looking to do is adjust the install scripts of the various things that check for ptrace using the following check:

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

And add a check against `getcap /usr/bin/wineserver` so that the installer will continue in either case rather than only if it's set globally. I've yet to have a problem with the actual function of games due to this, usually just the install process. 

My bash is a bit rusty so I won't embarrass my self by attempting to post a proper adjustment. Are the PlayOnLinux install scripts something that can be public contributed to? 

Edit: Just found the post that originally suggested to use setcap instead of setting it globally, it was a post you (petch) made a year ago. :)

Edited by PatriotBob

petch Saturday 11 May 2013 at 1:52
petch

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

booman Wednesday 19 June 2013 at 17:32
booman

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

Does anyone know anything about that?

† Booman †
Mint 21 64-bit | Nvidia 515| GeForce GTX 1650
Linux for Beginners | PlayOnLinux Guides | PlayOnLinux Explained
petch Wednesday 19 June 2013 at 19:41
petch

Yes, it contains the same code as above. It's unused since there has been no feedback about that suggestion.
booman Wednesday 19 June 2013 at 19:47
booman

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

† Booman †
Mint 21 64-bit | Nvidia 515| GeForce GTX 1650
Linux for Beginners | PlayOnLinux Guides | PlayOnLinux Explained
Ronin DUSETTE Saturday 13 July 2013 at 22:18
Ronin DUSETTE

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.

Please:
Post debug logs & full computer specs in first post
No private messages for general help, use the forums
Read the wiki, Report broken scripts
Quentin PÂRIS Saturday 13 July 2013 at 23:06
Quentin PÂRISAnonymous

Is this script reboot-proof?
Ronin DUSETTE Saturday 13 July 2013 at 23:24
Ronin DUSETTE

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?

Please:
Post debug logs & full computer specs in first post
No private messages for general help, use the forums
Read the wiki, Report broken scripts
petch Saturday 13 July 2013 at 23:31
petch

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.
Ronin DUSETTE Sunday 14 July 2013 at 0:17
Ronin DUSETTE

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

Please:
Post debug logs & full computer specs in first post
No private messages for general help, use the forums
Read the wiki, Report broken scripts
Ronin DUSETTE Sunday 14 July 2013 at 1:32
Ronin DUSETTE

Fixed it. :)

Works fine now. Menus and all.

Please:
Post debug logs & full computer specs in first post
No private messages for general help, use the forums
Read the wiki, Report broken scripts
Ronin DUSETTE Sunday 14 July 2013 at 3:59
Ronin DUSETTE

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:
Post debug logs & full computer specs in first post
No private messages for general help, use the forums
Read the wiki, Report broken scripts
Quentin PÂRIS Sunday 14 July 2013 at 14:12
Quentin PÂRISAnonymous

(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
Ronin DUSETTE Sunday 14 July 2013 at 19:00
Ronin DUSETTE

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

Please:
Post debug logs & full computer specs in first post
No private messages for general help, use the forums
Read the wiki, Report broken scripts
jantman Saturday 13 August 2016 at 17:49
jantman

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?

Arch Linux user & occasional contributor
tooling & automation developer during the day
Linux user since 2001
http://github.com/jantman - http://www.jasonantman.com - http://blog.jasonantman.com