For both of these cases, if you look in /var/log/messages you can see that AppArmor is rejecting access to /rofs/lib/tls/i686/cmov/libc-2.6.1.so
A simple fix is to update the profiles to use
{/rofs,/cow,}/lib/tls/i686/cmov/*.so
AppArmor can block access to stacked filesystem paths depending on how the stacked fs is implemented.
The quickest solution at the moment is to modify the profiles, so that permissions are given for the given prefix.
I would probably setup a variable in global
@{LIB}={/ros,/cow,}/lib
and modify profiles to use the variable.
@{LIB}/tls/i686/cmov/*.so
The other possible solution I can suggest is further modification of the unionfs patch for unionfs 2.x under AppArmor 2.1 code base. It is possible to further patch unionfs so that it passes the lower filesystem requests so that AppArmor doesn't mediate them. This would get rid of the need to update profiles as suggested above.
For both of these cases, if you look in /var/log/messages you can see that AppArmor is rejecting access to /rofs/lib/ tls/i686/ cmov/libc- 2.6.1.so
A simple fix is to update the profiles to use /cow,}/ lib/tls/ i686/cmov/ *.so
{/rofs,
AppArmor can block access to stacked filesystem paths depending on how the stacked fs is implemented. {/ros,/ cow,}/lib
The quickest solution at the moment is to modify the profiles, so that permissions are given for the given prefix.
I would probably setup a variable in global
@{LIB}=
and modify profiles to use the variable. tls/i686/ cmov/*. so
@{LIB}/
The other possible solution I can suggest is further modification of the unionfs patch for unionfs 2.x under AppArmor 2.1 code base. It is possible to further patch unionfs so that it passes the lower filesystem requests so that AppArmor doesn't mediate them. This would get rid of the need to update profiles as suggested above.