Snap version doesn't run under Debian

Lunacy version:
Snap version 9.1.1

OS version:
Debian 11

What I found was, that if I tried to run the Snap, the program would crash with the following output:

dirk@Proteus:~$ which lunacy
/snap/bin/lunacy
dirk@Proteus:~$ lunacy
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
Unhandled exception. System.Net.NetworkInformation.NetworkInformationException (13): An error was encountered while querying information from the operating system. ---> System.UnauthorizedAccessException: Access to the path '/proc/sys/net/ipv4/conf/lo/forwarding' is denied.
 ---> System.IO.IOException: Permission denied
   --- End of inner exception stack trace ---
   at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirError)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String path, OpenFlags flags, Int32 mode, Func`4 createOpenException)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, UnixFileMode openPermissions, Int64& fileLength, UnixFileMode& filePermissions, Func`4 createOpenException)
   at System.IO.Strategies.OSFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, Nullable`1 unixCreateMode)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, Int64 preallocationSize)
   at System.IO.StreamReader.ValidateArgsAndOpenPath(String path, Encoding encoding, Int32 bufferSize)
   at System.IO.File.ReadAllText(String path, Encoding encoding)
   at System.Net.NetworkInformation.StringParsingHelpers.ReadAllText(String filePath)
   at System.Net.NetworkInformation.StringParsingHelpers.ReadAllText(String filePath)
   at System.Net.NetworkInformation.StringParsingHelpers.ParseRawIntFile(String filePath)
   at System.Net.NetworkInformation.LinuxIPv4InterfaceProperties.GetIsForwardingEnabled()
   at System.Net.NetworkInformation.LinuxIPInterfaceProperties..ctor(LinuxNetworkInterface lni, LinuxNetworkInterfaceSystemProperties systemProperties)
   at System.Net.NetworkInformation.LinuxNetworkInterface.GetLinuxNetworkInterfaces()
   at System.Net.NetworkInformation.NetworkInterfacePal.GetIsNetworkAvailable()
   at System.Net.NetworkInformation.NetworkChange.OnAvailabilityTimerFired(Object state)
   at System.Threading.TimerQueueTimer.Fire(Boolean isThreadPool)
   at System.Threading.TimerQueue.FireNextTimers()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
   at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()
Aborted
dirk@Proteus:~$ 

Now, this is not a spectacular failure. It suggests to me that under Debian, Snaps are more heavily sandboxed than they are under Ubuntu.
And, I seem to be able to run the Flatpak version under Debian 11, without running into apparent stability issues.

Update:

I should add that I have AppArmor installed, and this could be adding to the problem. The only fact to know about that is, that Apparmor is applying one set of confinement rules for all Snaps, and if I were to deactivate that AppArmor rule, I’d be removing the AppArmor confinement of All Snaps (which I don’t feel comfortable doing).

Dirk

Dirk, it seems like an issue with the access to networking status. I think that it’s better to try to remove the confinement if you want to fix this issue.

Is there some reason why I shouldn’t be using the Flatpak?

Dirk

Lunacy doesn’t support Flatpak at the moment. We have this version in the works, but I can’t give you an exact ETA,

Aside from whether you have an ETA for the Flatpak version, I have the Flatpak version installed (9.1.1), and it seems to work.

Dirk

There’s an unofficial user-made Flatpak version of Lunacy. However, as I’ve mentioned before, we don’t support it yet.

I now understood you.

However, even if I disable the apparmor profile for snaps, first with Do Not Enforce, I get the same error. Then, I followed the advice at this link, to enable what that virtual file represents:

[command line - Bash /proc/sys/net/ipv4/ip_forward: Permission denied - Ask Ubuntu](Link to Ubuntu about that file.)

It looks like the snap is trying to find out whether IP forwarding is enabled, and is not even allowed to read the file.

The exact commands I gave as root were:

# aa-complain usr.lib.snapd.snap-confine.real
# ln -s /etc/apparmor.d/usr.lib.snapd.snap-confine.real /etc/apparmor.d/disable

And then, I rebooted. But to no avail, Snaps under Debian are still forbidden from accessing that file.

Also, I can do the following as user:

dirk@Proteus:~$ cat /proc/sys/net/ipv4/conf/lo/forwarding
1

So, it’s not as if a regular user wouldn’t have permission to read that file under Debian.
Is it possible that the snap is trying to write to that virtual file even though it’s not root?

Dirk

Okay.

The way to remove the confinement for one snap is, to install it in dev mode. When I did this with Lunacy, I was able to resolve the technical issue. It runs just fine now, thank you.

Of course, I won’t be receiving any updates like this, but so what? Version 9.2 is perfect. :wink:

Dirk