chroot into a snap

[Roberto Mier Escandón ]

Because this will use nextcloud documents, and they are internal to
nextcloud snap

On 09/02/17 14:33, Thomas Voß wrote:
> I think you want:
> 
>   https://github.com/snapcore/snapd/blob/master/interfaces/builtin/home.go
> 
> Why would you need to access documents in other snaps?
> 
> On Thu, Feb 9, 2017 at 2:26 PM, Roberto Mier Escandón 
> <roberto.escandon at canonical.com> wrote:
>> awsome Thomas!. You got it!. Having the doc in any snap path can be
>> rendered.
>> So, that answers the point of chroot working ok, but now there is
>> another problem: How can I access documents in other snaps? Can content
>> interface solve this? (I'll try)
>>
>> On 09/02/17 14:04, Thomas Voß wrote:
>>> 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
>>>>
>>>
>>
>> --
>> Snapcraft mailing list
>> Snapcraft at lists.snapcraft.io
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
>