Snap package misses /usr/share/[data]

[ijohnson]

@MrHaroldA

/etc/openal/alsoft.conf

For this file, you could try using a layout to a writable version of the config file somewhere in $SNAP_DATA, initially populating that file in the writable directory with one that is in $SNAP:

layout:
  /etc/openal/alsoft.conf: 
    bind-file: $SNAP_DATA/etc/openal/alsoft.conf

and then have your snap install hook copy the file from $SNAP (which is read-only) to $SNAP_DATA (which is writable):

#!/bin/sh -e

# check if the file is empty (snapd will create the empty file for us setting up a layout)
if [ -z "$(cat $SNAP_DATA/etc/openal/alsoft.conf)" ]; then
    cat $SNAP/etc/openal/alsoft.conf > $SNAP_DATA/etc/openal/alsoft.conf
fi

[MrHaroldA]

Right again!

Let’s see if I can figure this one out myself:

dec 18 19:14:18 x1 audit[20039]: AVC apparmor="DENIED" operation="mknod" profile="snap.brouwhulp.brouwhulp" name="/home/harold/snap/brouwhulp/x3/.brouwhulp/tmp" pid=20039 comm="brouwhulp" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
dec 18 19:14:18 x1 kernel: audit: type=1400 audit(1576692858.029:95): apparmor="DENIED" operation="mknod" profile="snap.brouwhulp.brouwhulp" name="/home/harold/snap/brouwhulp/x3/.brouwhulp/tmp" pid=20039 comm="brouwhulp" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

[MrHaroldA]

Nope; can’t figure that one out myself. It wants to create a directory in your home folder, which it has all rights to. But yet it is denied.

[ijohnson]

Do you know why your application would be trying to use mknod here (specifically why it’s using mknod)?

[MrHaroldA]

No clue; it’s a closed source binary blob.

[jdstrand]

@MrHaroldA

dec 18 19:14:18 x1 audit[20039]: AVC apparmor=“DENIED” operation=“mknod” profile=“snap.brouwhulp.brouwhulp” name="/home/harold/snap/brouwhulp/x3/.brouwhulp/tmp" pid=20039 comm=“brouwhulp” requested_mask=“c” denied_mask=“c” fsuid=1000 ouid=1000

Note the ‘operation’ is mknod, not the command. It is not unusual for the syscall to be used to create regular files. I suspect this denial is coming from a snap refresh/install happening while brouwhulp is still running since the profile is updated to allow read-only access for the prior revision.

[MrHaroldA]

It happens every time I launch BrouwHulp, so again … no clue

[MrHaroldA]

I have given up on snapping BrouwHulp, but man, the snap documentation is completely worthless.

I have another app I tried to package, which proved a total nightmare too.

1. /usr/share/[data] is missing again; seems that only the ‘command’ and ‘desktop’ files are copied?
2. Should I compile with a prefix other than /usr? Should I use a prefix like /snap/[package]/current/usr instead?
3. Layouts are for precompiled binaries where you can’t control the location of libraries, so I have to use ‘filesets’ and’ prime’, but then point 1 rises again.

I’m giving up on snap.

[rajat]

I am facing the same challenges. There is literally no real documentation for snapcraft. I am trying to do a classic snap for an application called Maitreya8, it is an astrology application, It throws errors that the directory /usr/share/maitreya or anything underneath does not exist. This is crazy…Does this problem really have no solution. Should I give up on snaps like everyone else.

[ogra]

is there any particular reason to make an astrology application classic instead of using strict confinement (in which case you can use layouts similar to how @ijohnson described it above but with whole directories)

[rajat]

yes, It needs to launch a pdf reader to view the astrological report that it generates. by default strictly confined snap does not allow for a second process thread from within the same snap, ( my understanding may be wrong). Hence packaging say evince withing the snap had no impact. With classic snap it can access evince but it fails to see the /usr/share/maitreya8 directory within the snap file structure. the snap uses autotools plugin…Layouts were used in strictly confined snap and it worked elegantly. for now I am using it without the pdf viewer fearure, Any help in getting the classic snap to see the file system within the snap will be much appreciated.

[James-Carroll]

If the aim is to open a pdf in strict confinement, you can open evince by using xdg-desktop-portals functionality, the easiest way to do this would be to simply make a call to xdg-open <path.pdf> in the apps code.

You can give it a quick try with

snap run --shell maitreya8
xdg-open <path-to-pdf>

to see how it would roughly work. It should open up a GUI where the user can select their preferred viewer to open the file.

[ogra]

@rajat

by default strictly confined snap does not allow for a second process thread from within the same snap, ( my understanding may be wrong).

yes, your understanding is definitely wrong snaps allow you to package and run as many apps as you want in one snap, there are no limits here (apart from … well, ram and cpu of the host)

note that “launching a pdf viewer” is not enough to get permissions to upload your snap as classic … what james describes is the corrct way, make the app use xdg-open and it should just work with any modern desktop.

[rajat]

That sounds promising, However the application has a configuration window where it asks you to select the default pdf viewer.It looks for a command path. With strict confinement it does not seem to work. With classic everything works fine but the application complains while using, that it can’t see the /usr/share/maitreya8 folder or any folders within.

[rajat]

I will do exactly as advised by James within strict confinement. I am happy to package evince long with the application within the strict confinement, I would need a way to to let the application call evince as needed. If that can be achieved we are good to go without any need for classic snaps. I will try what James has suggested, I will advise how It goes

[James-Carroll]

Just to be sure, you don’t need to package Evince in the snap if you’re expecting users to already have it (or another .pdf viewer, such as basically any web browser). xdg-open will find compatible apps on the host, including any other possible pdf viewers such as Firefox/Chrome/etc

[ogra]

just for the record, here is the list of criteria to get classic confinement allowed by the reviewers:

Process for reviewing classic confinement snaps

Classic confinement review process Background As of snapd 2.20, snappy supports confinement: classic which allows the snap to run without restrictions. Future releases of snapd will also support a classic interface (name TBD) that operates similarly. Snaps specifying classic confinement may target the stable channel, but are only supported on classic distro systems (ie, not on Ubuntu Core). Because classic confinement snaps run without restrictions, use of classic confinement effectively grants…

[rajat]

Thanks @ogra it is really helpful. I will keep working towards making the strict confinement work. Will open a new thread in case I get stuck, I guess the scope of this tread ends here as will no longer face the issue described here in this title, my problem is different now, it concerns launching secondary applications to support the primary one. Many thanks for your valuable guidance.

[rajat]

It has finally worked and I am ready to finally upload my first snap to the store for publishing. I may have to supplement the snap with instructions on how to configure the command line for the pdf editor to point to /bin/xdg-open. That would be there with the description of the snap, i hope that is enough to get this through into the store…Again many thanks for your support.

[ogra]

dont you have a way to put a default config in place that simply includes that command ? (through a command-chain wrapper script or such ?)