Provisional snap for DUB (D language package/build manager)
Joseph Rushton Wakeling
joseph.wakeling at webdrake.net
Tue Nov 1 21:31:46 UTC 2016
On 27/10/16 22:13, Joseph Rushton Wakeling wrote:
> On 27/10/16 08:37, Didier Roche wrote:
>> I would look at /var/log/syslogs. Apparmor and seccomp denials are
>> listed there. Note that if you didn't already, you should really start
>> developping your snap in devmode. That way, it will get confinment out
>> of the equasion to get your relocatable code and dependencies working.
>> Then, we can turn on confinement and figure out those issues to be able
>> to publish in the stable channel.
> Yea, I probably should have started with devmode. Thanks for the advice about
> syslogs; I'll check it out and see what I can find.
OK, so it looks like apparmor was indeed responsible. The loglines in question:
Oct 30 17:50:50 computername kernel: [ 9532.992875] audit: type=1400
audit(1477846250.853:43): apparmor="DENIED" operation="link"
name="/home/username/code/D/dgraph/build/dgraph_graphtest" pid=22464 comm="dub"
requested_mask="l" denied_mask="l" fsuid=1000 ouid=1000
Oct 30 17:50:50 computername kernel: [ 9533.035303] audit: type=1326
audit(1477846250.897:44): auid=4294967295 uid=1000 gid=1000 ses=4294967295
pid=22464 comm="dub" exe="/snap/dub/x1/bin/dub" sig=31 arch=c000003e syscall=92
compat=0 ip=0x7f9b72d13717 code=0x0
I'm not experienced with apparmor, so could someone explain exactly what this
means? (I get the general idea, but the specifics would be useful to understand
In particular, is there an obvious reason why this might be showing up with the
dub snap, when the earlier ldc2 snap didn't have this problem? I would guess
because the ldc2 instance used by the snap-packaged dub is internal to the snap
and does not benefit from the home-directory interface that dub itself gets?
Setting the containment to devmode removes the problem, but it would be nice to
be able to have strict confinement earlier rather than later.
More information about the Snapcraft