Can system-files interface allow to access system /lib/{specific}.so or /usr/lib/{specific}.so?

snapcraft
1

I dont know if system-files interface can achieve this ? or i need a classic confinement ?

2

Hello ! @aoyama .

Maybe a solution to your question is there.

3

Thank you! But if i understand correctly, layout exposes file in snap to the outside host. I want the opposite, let snap can access the host’s library.

4

<target-path> can include nearly any path except for:

  • /boot
  • /dev
  • /home
  • /lib/firmware, /usr/lib/firmware
  • /lib/modules, /usr/lib/modules

Also i see layout don’t allow to access /lib or /usr/lib

5

The idea was to make elements located in $SNAP, $SNAP_DATA and $SNAP_COMMON accessible from locations such as /usr, /var, /etc. But I see that’s not what you want.

1 Like
6

System files can achieve it, but can you be sure it’s what you want?

The vast majority of libraries do not have ABI compatibility guarantees and even those what do tend to only have it one way (e.g Glibc is forwards compatible only).

If it’s a library we can’t avoid like NVidia drivers it’s probably already added as a workaround automatically. As you start drifting away from specific pieces like NVidia’s drivers into more generic territory, you don’t have the guarantee’s stuff like NVidia has. And even NVidia’s guarantees are weak, some of the newer driver versions don’t work with the older cores!

In summary it might sound like this is the perfect solution to your problems, but even in classic, snaps don’t just randomly pull external libraries into their runtime because the idea very rarely works for anything non-trivial. There’s logic in classic snaps that ensures they pull from the core snap and themselves as much as they can, and when this doesn’t work for whatever reasons, even the classic snaps break from host libraries, in the non-graceful “This just crashes and loses all my data” manner.

What you’re asking comes down to “Can I run two operating systems at the same time” and the answer is always a “Kinda but stuff will break when they overlap”.

The much simpler answer is to bundle them with your snap where you can and should always be the first choice.

1 Like
7

I think, a scenario like this could work, but the operation could be annoying. :slightly_smiling_face:

name: foo

plugs:
  etc-foo:
    interface: system-files
    read:
    - /etc/foo

apps:
  foo:
    plugs:
    - etc-foo
8

I’m quite confused with the post and so it’s a bit hard to provide any meaningful suggestion. Can you please clarify which library you need to access and why?

9

I try to pack rstudio as snap, but rstudio need to access R language library(/lib/libR.so).

10

Is rstudio a classic snap? Are you shipping packaged R runtime with the snap as well or do you plan to use what is available on the host?

11

Just some experiments, the rstudio name has not been registered yet.

And yeah, i try to not ship whole R runtime cause it will make snap oversize.

12

Most IDEs end up being classic snaps where what you describing is possible. This is in fact a valid use case for building your snap as classic rather than strictly confined.

1 Like