Provisional snap for DUB (D language package/build manager)
Joseph Rushton Wakeling
joseph.wakeling at webdrake.net
Sun Nov 13 09:11:52 UTC 2016
On 03/11/16 11:49, Joseph Rushton Wakeling wrote:
> On 01/11/16 22:43, Sergio Schvezov wrote:
>> If this is x86_64, everything is aligned with the world, syscall 92 is chown. A
>> useful tool here can help you out, and luckily there is one, run `snap install
>> snappy-debug` and it will do some nice things to figure out what is going on wth
>> these apparmor and seccomp blockers.
> Cheers, I'll try that out. Will probably be a little while before I follow up
> -- I'm going to be away from computer for the next couple of weeks.
Sorry for delayed response; I was on vacation and very deliberately AFK ;-)
>> If this is the problem and you can patch the software then removing the chown
>> could work, I am CCing Jamie for other ideas that could come up.
Looking at the dub source code, it seems that the actual build -- i.e. the
compiler call that generates the binary -- writes to a temporary .dub/ directory
created in the project tree, and the generated files are then copied to the
user-perceived output location, with chown and chmod calls to preserve the
That seems a reasonable enough approach in itself, but is it possible to
preserve that basic operational principle without hitting the block on chown?
The `copy` function called earlier on L115 actually has an optional `preserve`
parameter that allows file attributes to be maintained during the copy; it might
be worth trying this out to see if that doesn't hit the blocks from the
container, although it still does a chmod:
... so whether that would work would presumably hinge on whether chmod is also
forbidden by containerization, or just chown.
It's not obvious to me why the author of the dub code has instead created a
POSIX-specific control block to set permissions manually, so I'll check out that
with the dub folks.
More information about the Snapcraft