On 10/01/17 08:44, Olivier Tilloy wrote:
> On Tue, Jan 10, 2017 at 2:41 PM, Jamie Strandboge wrote:
>> On Wed, 2017-01-04 at 13:39 +0100, Olivier Tilloy wrote:
>>> Here is the bug report: https://launchpad.net/bugs/1653955
>> Thanks! The fix is in master and will bi in snapd
On Tue, Jan 10, 2017 at 2:41 PM, Jamie Strandboge wrote:
> On Wed, 2017-01-04 at 13:39 +0100, Olivier Tilloy wrote:
>>
>> Here is the bug report: https://launchpad.net/bugs/1653955
>
> Thanks! The fix is in master and will bi in snapd 2.21.
Excellent, thanks Jamie for your
On Wed, 2017-01-04 at 13:39 +0100, Olivier Tilloy wrote:
>
> Here is the bug report: https://launchpad.net/bugs/1653955
Thanks! The fix is in master and will bi in snapd 2.21.
--
Jamie Strandboge | http://www.canonical.com
signature.asc
Description: This is a digitally signed
On Tue, Jan 3, 2017 at 8:21 PM, Jamie Strandboge wrote:
> On Mon, 2017-01-02 at 16:34 +0100, Olivier Tilloy wrote:
>> Hi everyone, and happy new year!
>>
>> I’m snapping an app that makes use of semaphores¹ and seeing an
>> apparmor denial. The glibc implementation of
On Mon, 2017-01-02 at 16:34 +0100, Olivier Tilloy wrote:
> Hi everyone, and happy new year!
>
> I’m snapping an app that makes use of semaphores¹ and seeing an
> apparmor denial. The glibc implementation of sem_open calls
> SHM_GET_NAME(EINVAL,SEM_FAILED,SEM_SHM_PREFIX) where SEM_SHM_PREFIX is
>
Hi everyone, and happy new year!
I’m snapping an app that makes use of semaphores¹ and seeing an
apparmor denial. The glibc implementation of sem_open calls
SHM_GET_NAME(EINVAL,SEM_FAILED,SEM_SHM_PREFIX) where SEM_SHM_PREFIX is
"sem.", so it tries to create /dev/shm/sem.{name}, which fails