glGetUniformLocation fails in confinement mode

[Didier Roche]

Le 30/01/2017 à 15:39, Jamie Strandboge a écrit :
> On Mon, 2017-01-30 at 08:47 -0500, Stephen M. Webb wrote:
>> On 2017-01-30 01:56 AM, Spencer Parkin wrote:
>>>
>>>
>>> I have a program that has successfully snapped and run in confinement mode,
>>> but then I added a pixel and vertex shader
>>> which works when run on my classic system, but not in strict confinement as
>>> a snap.  I've tried to narrow down the
>>> earliest fail point, and I believe it is at the point where I'm calling
>>> glGetUniformFromLocation.  This is returning -1
>>> in confinement mode.  I'm able to read, compile and link my shader program,
>>> and bind it, but the first call to
>>> glGetUniformFromLocation fails.  Is OpenGL being denied read-access to a
>>> portion of protected memory?  If so, it
>>> certainly would fail to write there as well with a call to glUniform3f, for
>>> example.
>>>
>>> I've tried hooking up the snappy-debug's log-observe plug to that of ubuntu
>>> core's, then running the scanlog, but the
>>> only app-armer denial I get is, I believe, unrelated to the problem.  In any
>>> case, I will give it here...
>>>
>>> Log: apparmer="DENIED" operation="open"
>>> profile="snap.twistypuzzle.twistypuzzle" name="/usr/share/glib-2.0/schemas/"
>>> pid=23593 comm="desktop-launch" request_mask="r" denied_mask="r" fsuid=1000
>>> ouid=0
>>> File: /usr/share/glib-2.0/schemas/ (read)
>> That error message is because the launcher program "desktop-launch" can not
>> find the gsettings.  I don't know what
>> impact that will have (if any) but it's not going to affect how OpenGL works
>> internally.
>>
> AIUI, the desktop part is doing this as part of its bootstrap to generate what
> it needs in ~/snap/SNAP_NAME/SNAP_REVISION and it will only do this the first
> time a new revision of the snap is launched. This denial is harmless and should
> only happen on classic (since /usr/share/glib-2.0/schemas doesn't exist on
> Ubuntu Core).
> 
> While harmless, it is also confusing. I'm not super familiar with the desktop
> part and wonder how we can improve this. Didier or Seb, would the bootstrapping
> process work ok if we allowed read on the /usr/share/glib-2.0/schemas/ directory
> in the unity7 (and maybe the x11) transitional classic interfaces?
> 

The issue is indeed that there is classic confinement vs core only. I
thought that it makes sense to read all traditional glib schema paths,
test that they exists, and if they exist, compile the gsetting schemas
alongside the snap specific ones.

/usr/share/glib-2.0/schemas/, as Jamie told, don't exist on core, so we
just skip it and don't have that denial. On classic however, it does.

I'm surprised thought hat there is even a denial: I thought classic gave
you access to your whole host system and this kind of things won't
happen, do you mind giving some precisions Jamie to fix my twisted
perception?

For the paths we are checking, we are basing ourself on $XDG_DATA_DIRS,
appending glib-2.0/schemas to each of them.
On 16.04 LTS, this is:
$ echo $XDG_DATA_DIRS
/usr/share/ubuntu:/usr/share/gnome:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop

As you can see, quite some paths are involved (even if in practice, only
/usr/share/glib-2.0/schemas/ would exist in general).
Hope that helps clarifying out!
Cheers,
Didier