/snap/bin not in $PATH on desktop

Jamie Strandboge jamie at canonical.com
Fri Sep 9 13:25:49 UTC 2016


On Fri, 2016-09-09 at 09:41 +0200, Sylvain Pineau wrote:
> On 07/09/2016 16:20, Zygmunt Krynicki wrote:
> > 
> > > 
> > > On 7 Sep 2016, at 13:16, Sylvain Pineau <sylvain.pineau at canonical.com>
> > > wrote:
> > > 
> > > Hello,
> > > 
> > > I noticed that I was not able to call other snap commands from my own snap
> > > on my desktop.
> > > So I tested what was defined using the hello-world.env command.
> > > 
> > > On desktop (with ubuntu-core 16.04.1 rev 352)
> > > 
> > > $ hello-world.env | grep ^PATH=
> > > PATH=/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
> > > 
> > > But on a true snappy system (with ubuntu-core 16.04.1 rev 453), I get:
> > > 
> > > $ hello-world.env | grep ^PATH=
> > > PATH=/home/ubuntu/bin:/home/ubuntu/.local/bin:/usr/local/sbin:/usr/local/b
> > > in:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
> > > 
> > > Is there any reason to not have /snap/bin as part of the $PATH available
> > > to snap commands?
> > Snaps cannot execute other snaps. The PATH difference is caused by how snap-
> > confine behaves when it runs on classic but in general even if you used an
> > absolute path you would not be able to start any other applications from
> > /snap/bin. Allowing this would create an implicit interface (dependency
> > between your snap and some other, perhaps third party, snap).
> > 
> > If you need access to executables that you control you can use the content
> > interface to bind mount another snap into your own snap and execute those
> > commands directly, with the same security profile as the running
> > application.
> > 
> > Best regards
> > ZK
> > 
> Let me add some context to my initial post.
> Basically we need to test other snaps (commands) from our checkbox test 
> runner (a different snap).
> The issue I mentioned above was the ability to run docker commands from 
> the checkbox snap.
> Both were installed with --devmode.
> But I'm not the owner of the docker snap so using the content interface 
> won't work for us.
> Let's consider we're just the owner of the checkbox snap.
> We could add /snap/bin to our own wrappers but it seems to be a bad 
> practice.

Since snaps aren't expected to be able to launch programs from /snap/bin for the
reasons already mentioned, I would argue that snapd should strip /snap/bin from
the PATH for launched commands to avoid confusion. checkbox and things that
launch other snaps' commands via devmode are the outliers and it seems perfectly
reasonable to me for them to add /snap/bin to their PATH via wrappers.

-- 
Jamie Strandboge             | http://www.canonical.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20160909/880294af/attachment.sig>


More information about the Snapcraft mailing list