chroot into a snap

[Thomas Voß]

On Thu, Feb 9, 2017 at 11:35 AM, Roberto Mier Escandón 
<roberto.escandon at canonical.com> wrote:
>
> Hey Thomas,
>
> You can find the snap at [1]
> Atttached are traces for:
>
> Devmode:
> - service.txt are the logs of the service
> - syslog.txt and snappy-debug.security.txt are the logs to see apparmor
> denials (warnings in this case). I cannot see more than ptrace ones.
>
> Classic:
> - service.classic.txt
> here i don't see any denial
>
> The only error shown is that the document has not been found. But the
> url is the same in classic or devmode, so that's not the reason of the
> problem.
>

Okay, so I don't see the chroot setup failing at all (according to
your logs). Where is the document located in the local file system?
If your snap works with classic confinement, it might live outside of
the snap itself.

>
> [1] https://github.com/rmescandon/loolwsd-snap
>
> BR.
>
> On 09/02/17 10:32, Thomas Voß wrote:
>> Hey Roberto,
>>
>> On Wed, Feb 8, 2017 at 4:54 PM, Roberto Mier Escandón 
>> <roberto.escandon at canonical.com> wrote:
>>> Hey engineers,
>>>
>>> I need some ideas to solve this: I'm trying to snap collaboraoffice
>>> online but that's not being easy at all. FYI: this is a kind of Google
>>> Drive stuff so that when you request in your browser certain document,
>>> it is rendered and can be edit by many at the same time, etc..
>>>
>>> Though I've been able to build from sources a snap package, that is only
>>> working in classic confinement but not in devmode or strict.
>>>
>>> The reason is because the way it works:
>>> - There is a server listening for documents requests
>>> - for every new document requested an instance of a document manager is
>>> started in a chrooted environment
>>> - If requested n documents there will be n different chroot jails based
>>> in same certain template
>>> - document manager has certain linux capabilities to create the needed
>>> roots (cap_fowner,cap_mknod,cap_sys_chroot...)
>>> - the way of packaging the snap, currently, is by setting those caps and
>>> call mksquashfs skipping -no-attrs option set by default by snapcraft
>>>
>>
>> Could you please elaborate what is not working and how it fails?
>> System logs, apparmor denials
>> and seccomp messages would be needed here for further debugging.
>>
>> What is going wrong in the devmode case?
>>
>> Thanks,
>>
>>   Thomas
>>
>>> I thought about a solution of having server in a snap and document
>>> manager in another, but still there would be needed calling chroot for
>>> every new document... ideas?
>>>
>>> BR.
>>>
>>> --
>>> Snapcraft mailing list
>>> Snapcraft at lists.snapcraft.io
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
>>
>
> --
> Snapcraft mailing list
> Snapcraft at lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
>