How to access /usr/local/share/ca-certificates

snapd
1

Hi,

my snap connects to OpenStack, to accomodate custom CAs I’d like to give it access to /usr/local/share/ca-certificates

Based on a comment on bug #1901586 I attempted to do this via the system-files interface, but that didn’t work out quite right:

plugs:
  ca-certificates:
    interface: system-files
    read:
    - /usr/local/share/ca-certificates

apps:
  foo:
    command: bin/foo
    plugs:
      - home
      - network
      - ca-certificates

Any pointers?

2

Bump – anyone at all?

I’m a bit confused about the system-files interface tbh. But I don’t see any other interface that would allow me access under /usr, but its very possible I’m missing something. Otoh, grepping through snapd/interfaces/builtin I don’t see /usr/local/share/ca-certificates anywhere, nor any apparmor rules for some parent dir that seems viable

3

/usr/local/share/ for a strictly confined snap will come from the base snap, not from the host system, so if you are installing certificates to that directory on the host, strictly confined snaps will not see this directory.

The caveat to this is that recently (I think somewhere around snapd 2.48 - not sure), we started mounting /etc/ssl/ for strict snaps (that use the core, core18 or core20 base snaps) from the host system on specifically classic ubuntu or debian systems. So I think all you need to do is to move your custom certificates to /etc/ssl instead of /usr/local/share/ca-certificates and hopefully they are picked up automatically.

4

Yup, getting certs from /etc/ssl/certs seems to work out ok with snapd 2.51.1 (it doesn’t with 2.48.3).

Tbh I wonder a bit about /usr/local access – per FHS this is for the sysadmin to install local software. Isn’t masking it out via snaps a bit at odds with the FHS intent?

Think I’ll probably not be the only one stumbling across this, also cf. that bug #1901586

Thanks, peter.

2 Likes
5

Well sort of, but the larger feature that overrides this desire is to insulate snaps from the host system’s dependencies in that we want snaps to continue running no matter what the host system is, so the snap should not be influenced by new updates to dynamic libraries on the host system, etc. and instead only views very specific parts of the host filesystem that are opened up to it, and it relies on the stable base snap for everything else.

6

The insulation does make sense.

On the other hand, I feel that snap authors could be given some flexibility here too. E.g. if I know that my snap is never going to load libs from /usr/local/share/ca-certificates there would be no harm in allowing access, possibly via a manual-only interface if there are security concerns.

The only alternative I see at the moment (ICBW) are --classic snaps, giving much broader access.

7

I second @petersabaini thoughts. As a sysadmin, following FHS as much as possible allows for more maintainable systems. While I do understand Snaps POV of isolation from host’s libs and all, there are points where this interaction is both inevitable and desirable.

I’m being the worst kind of person here, bringing in a problem, but not proposing a solution, I know; but I just want to make sure you people know that there’s “demand” for this.

8

It’s definitely a conscious decision we made to deviate from FHS which from our point of view has enough benefits to out-weigh the costs, and we are open to adding features like the /etc/ssl feature to make this easier.