snapcraft 2.27 has been released

[Sergio Schvezov]

On Sat, 18 Feb 2017 01:12:46 +0100, Joseph Rushton Wakeling wrote:
> On 17/02/17 13:49, Sergio Schvezov wrote:
>> ## classic confinement
>>
>> Improvements have been made to the experimental `classic` 
>> confinement build setup to be more robust and reliable. These 
>> improvements allow to build `classic` confined snaps that work 
>> across a wider set of OS releases (particularly those with 
>> differing glibc versions). An early adopter of this work is 
>> *conjure-up* which now sports Trusty Tahr support. Learn more 
>> about conjure-up by visiting http://conjure-up.io/
>
> I have good news and bad news here.
>
> The good news is that `snapcraft cleanbuild` now seems to work with classic 
> snaps (presumably you knew this already;-).

Still good to know!

> The bad news is that running the snapped applications seems to 
> run into trouble. 
>   I'm presuming this is a snapcraft issue rather than snapd since 
> already-installed classic snaps built with snapcraft 2.26 seem fine.

This is due to the fact that we are not setting up any environment variables from snapcraft for classic snaps to not override anything on the environment you'd want to run.

> Specifically, given the snap defined in this branch:
> https://github.com/WebDrake/dub.snap/pull/5

added a comment.

> ... it builds fine (with or without `cleanbuild`), and installs 
> fine, but when I 
> try to run even something simple like
>
>      dub --version
>
> ... then the command hangs.  Watching `top` sees CPU jump to 
> 100%, alternating 
> between dub, snap-exec and snap-confine.
>
> Running `snappy-debug.security scanlog` reveals the following 
> after the `dub` 
> command is invoked:
>
> = AppArmor =
> Time: Feb 18 01:07:30
> Log: apparmor="DENIED" operation="file_inherit" 
> profile="/usr/lib/snapd/snap-confine" name="/dev/tty" pid=7488 
> comm="snap-confine" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=0
> File: /dev/tty (write)
> Suggestion:
> * add 'serial-port (with gadget or core support)' to 'plugs'
>
> ... while the `dub --version` command outputs to console:
>
> runtime/cgo: pthread_create failed: Resource temporarily unavailable
> runtime/cgo: runtime/cgo: runtime/cgo: runtime/cgo: pthread_create failed: 
> Resource temporarily unavailableruntime/cgo: runtime/cgo: 
> pthread_create failed: 
> Resource temporarily unavailable
> runtime/cgo: runtime/cgo: pthread_create failed: Resource 
> temporarily unavailable
> runtime/cgo: pthread_create failed: Resource temporarily unavailable
> runtime/cgo: pthread_create failed: Resource temporarily unavailable
> runtime/cgo: pthread_create failed: Resource temporarily unavailable
> runtime/cgo: pthread_create failed: Resource temporarily unavailable
> runtime/cgo: pthread_create failed: Resource temporarily unavailable
>
> ... repeating seemingly endlessly.
>
> Note the above results whether or not the snap was built using `cleanbuild`.
>
>
> Possibly relatedly, while running `snapcraft cleanbuild` to 
> build this snap, the 
> following shows up in the scanlog:
>
> = AppArmor =
> Time: Feb 18 00:59:46
> Log: apparmor="DENIED" operation="file_perm" 
> namespace="root//lxd-snapcraft-truly-ace-amoeba_<var-lib-lxd>" 
> profile="/sbin/dhclient" name="/apparmor/.null" pid=30305 comm="dhclient" 
> requested_mask="w" denied_mask="w" fsuid=165536 ouid=0
> File: /apparmor/.null (write)
> Suggestion:
> * adjust program to write to $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or 
> $SNAP_USER_COMMON
>
> = AppArmor =
> Time: Feb 18 00:59:46
> Log: apparmor="DENIED" operation="file_perm" 
> namespace="root//lxd-snapcraft-truly-ace-amoeba_<var-lib-lxd>" 
> profile="/sbin/dhclient" name="/apparmor/.null" pid=30305 comm="dhclient" 
> requested_mask="w" denied_mask="w" fsuid=165536 ouid=0
> File: /apparmor/.null (write)
> Suggestion:
> * adjust program to write to $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or 
> $SNAP_USER_COMMON
>
> Any ideas what's up here?

This is the way exec works. To illustrate, create a file in PATH called, `eternal`

$ cat > /usr/local/bin/eternal << EOF
#!/bin/sh

exec eternal
EOF
$ chmod +x /usr/local/bin/eternal

If you exec that you will see the same behavior (I wish snap-confine added some protections for that though).

So in your specific case your snap is called `dub` has an app named `dub` which has a `command: dub`, what ends up happening is that `dub` is called from the entry in `/snap/bin/dub` which links to our internal command wrapper which has `exec dub` and the `dub` which takes precedence in PATH is `/snap/bin/dub`.

As I write this I think there is a clever trick we can try on snapcraft. Mind logging a bug for this please? I'll try and solve it for the next release which is next week.

--