[Mesa-dev] [PATCH 6/7] mesa: Skip looking at debug environment variables when setuid.

[Jose Fonseca]

----- Original Message -----
> On 03/20/2012 03:23 PM, Eric Anholt wrote:
> > On Thu, 8 Mar 2012 13:37:46 -0800 (PST), Jose
> > Fonseca<jfonseca at vmware.com>  wrote:
> >> FWIW, I think that debug builds of Mesa should allow debugging
> >> options
> >> all the time. Secure installs should use release builds.
> >>
> >> The added code lines are not portable, so they need to be compiled
> >> conditionally . At least #if !defined(_WIN32) ... #endif .
> >
> > I see plenty of recommendations in google that people compile with
> > --enable-debug, and optional package repositories that mention
> > turning
> > it on.  I don't think we should give those people security issues.

Frequency of Google results proves very little: I also see plenty of links to binaries in google from untrusted sources, and their frequency doesn't make them any more secure.
 
> I agree with Eric---I don't think it's wise to let normal users be
> able
> to make the setuid X server write misc. files.  Yes, installing in
> release mode should mitigate this, but debug mode is pretty common.
>  I'd
> rather err on the side of caution.

Call me old fashioned, but I think that debug builds are meant to be debugged (ie. test deployment), and release builds to be released (ie production evnironment). Giving the illusion that debug builds are more secure in some sense at the expense of making them harder to debug in some cases is just blurring their goals.

LD_LIBRARY_PATH/LIBGL_DRIVER_PATH are already ignored for setuid processes, so "sudo make install" is the only way that a setuid program would pick a debug build of a shared object. And honestly, nobody in their right mind should ever do "sudo make install" with debug builds, of any project. 

I wish I could say I don't care either way but truth is that VMware Workstation/Player and X.Org Server are two setuid programs that use GL, both of them close to me, so it is possible I'll need to debug GL on them any time, and I'd really hate to chase down and undo all setuid checks when I do.

So, if you really feel you must disable debugging features for setuid processes, then please wrap these changes in a #ifndef DEBUG_INSECURE .. #endif, or another name you like, so it can easily be reverted locally when I need to, by adding this define to the build.

> Perhaps add a _mesa_is_setuid() function that does getuid() !=
> geteuid()
> on Linux and return 0 on Windows?

Yeah, that should do it.

Jose