To make the review of your request easier, please use the following template to provide all the required details and also include any other information that may be relevant.
supported-category: none (at worst unsupported: dependent software only available on host)
reasoning: see below
I have very little hope that this will be accepted because of the unsupported category, yet it would be a bummer to know there’s no way to publish my app on Snap.
SamRewritten is an app which sole purpose is to interact with another app, Steam (by Valve). Most precisely the snap version of SamRewritten would only interact with the snap version of Steam.
SamRewritten needs to access files under the following path: $HOME/snap/steam/common/.local/share/Steam/…
Using a layout doesn’t work because I need to map $HOME.
Using personal-files doesn’t work because I need to load a shared object file (steamclient.so). Loading it fails using strict confinement.
How exactly, what are the errors ? If the .so is in the path and you have access through personal-files there should be nothing blocking you from loading it …
(and indeed you are correct, no category means no way to get classic unless you have a very good reason that could convince an architect to permit an override (“it’s a bummer” is not one) but lets see if we can’t make it work with existing interfaces )
Thank you for taking the time to review my request!
The error I get while attempting to load the library is the following:
/home/paul/snap/steam/common/.local/share/Steam/linux64/steamclient.so: failed to map segment from shared object
I can open the file just fine and read it from the application, so I concluded personal-files grants me the necessary privileges but the confinement itself prevents me from executing the syscalls required to load the file in memory.
If there is a recommended way to debug let me know, so far this is how I access AppArmor logs:
During testing, you’ll always have to connect this interface manually, without an explicit snap connect command, it’s only defined, not enforced.
I could anticipate some potential for problems as I know that $HOME/snap is treated slightly differently than most folders in $HOME, because one snap can’t access another snaps $SNAP_USER_COMMON or $SNAP_USER_DATA by base policy even with the home interface, but I’d have thought AppArmor should still allow the explicit path from personal-files due to increased specificity.
Ultimately though, I don’t think the file access alone is likely to be your issue here, since I’d presume that even if you can successfully load the library into the process; the implementation of the library suggests some kind of IPC, and being in a strict environment, you’ll likely find that DBus call/ Unix Socket / shm / etc to be likely impossible to conduct, but also also unlikely to qualify for classic.
Ensure the connection is working anyway and let us know, but I think you might have unfortunately tried an awkward package for even experienced snappers.
Run the snappy-debug snap in a terminal whilst running samrewritten, it’ll collate a few other common sandbox logs and sometimes offers actionable advice.
Is there any way to configure the Snap to allow this file_mmap operation with AppArmor ?
Even if I can get the library loaded, if IPC with outside processes are also likely impossible to conduct, then it might kill the idea of distributing the app with Snap, unfortunately. It would be nice to give it a shot first, if possible though.
Thanks for the request. As already said I don’t think this request fits classic confinement requirements requirements.
Is there any way to configure the Snap to allow this file_mmap operation with AppArmor ?
personal-files only allow read/write operations, so it cannot be done via personal-files. However, it should be possibly to fix this issue by staging steamclient.so in your snap if I’m not mistaken
If there is no further IPC and such but all you need is to have the .so mapped in ram, you could indeed have an install hook or something similar that simply copies it into your own $SNAP_COMMON using system-files and load it from there … (I.e. if you can not stage the file yourself)
I cannot stage steamclient.so inside of the Snap because it can be updated by Steam and must be of the same version.
Following your suggestions, I copied the file inside of SNAP_USER_COMMON, and the library loaded from there without issues.
Very surprisingly, there doesn’t seem to be issues communicating with Steam as everything loaded first try.
To summarize, it is technically possible to use personal-files to package my application, but it requires Snap-specific workarounds. Snap is slowly maturing, I would love to see it evolve allowing flagging personal-files with read+exec to avoid this confusion, or addressing this scenario in a more elegant way.
I would not have found out all of this without all of you, thank you for guiding me in the right direction and all the work you’re doing around Snap.
I will now work on packaging SamRewritten for strict confinement… again!
I was going to comment earlier, the home interface must already grant this, it’s possibly pointless personal-files being an exception, given you’ve shown that functionally all you’d change is relocating the file before executing it, it’s only creating undue hinderance when it exists behind a store restriction anyway.
It’d need to go through security approval, but I think there’s an argument to be made in letting you do this via changing personal-files to include mmap. I have a snap that produces .SO files at runtime (being a C++ interpreter itself) and runs them directly from $SNAP_REAL_HOME, this is given automatically. Right now we have no ability to grant you this access with personal-files even with explicit consideration, the two seem contradictory to me. I can understand why the exclusion exists, but home would be just as susceptable to e.g., ABI incompatibilities as personal-files would if that was the main thoughts behind this.
I can imagine that, whilst rare, there could be other valid cases for loading dynamic libraries from personal-files; you could have e.g., extension API’s in a program that use dynamic libraries, it’s common in e.g., digital audio workstations, so if they had other valid reasons using this interface already, they could run into bugs for not having as much as they expect, it could at least be configurable?
That’s actually fairly interesting because I’m left wondering how exactly it’s done and wouldn’t have expected it to work.
Glad to see this makes progress and pushes what’s possible though
The other reason this topic is fairly technically awkward, is because in the ideal snap world, the steam snap would actually contain the Steam runtime itself, rather than download it and run it external to $SNAP. This would allow it to expose that file as a content interface. I don’t think this would be available to $SNAP_USER_COMMON though where Steam actually runs, but that’d be the more ecosystem intended way of doing this were it not for the update mechanism of Steam specifically.
)