rem is a small tool for remembering things on the command line.
rem stores its data in hidden .rem files. Default global one is $HOME/.rem, but the user can also save commands/strings depending on directories by initialising a .rem file directly in a directory (by executing rem here).
So without classic confinement the app cannot be published in the stable channel, because the user is unable to save information with rem in its intended way.
Cheers
Martin
If all that āremā needs classic for is to store files in $HOME/.rem, why not have it properly honor $HOME, which is set to /home/user/snap/<snapname>/<revision>? If you did that, you wouldnāt even need the āhomeā interface since the ā.remā files would be stored in /home/user/snap/<snapname>/<revision>/.rem.
Rem needs not only write a .rem file in $HOME; but should also be allowed to write a .rem everywhere the user wants.
Would adjusting for $HOME and plugging the āhomeā interface work then? This is how most snaps work today-- for example, it is understood that while technically LibreOffice as non-snap could write to $HOME/.ssh or $HOME/.foo, in practice people donāt write to these hidden directories and the security benefit of not being able to write to hidden configuration data and sensitive files like ssh and gpg keys outweighs the limitation of not being able to write to $HOME/.foo.
As rem writes hidden files, home-interface would not be an option.
But as there are other problems for rem with snap packages ($PATH for example), I would withdraw from my request for classic confinement!
I may have not been clear on a couple of things. I was saying that if rem properly honored $HOME, then it would write its default hidden files fine in ~/snap/rem/current/.rem and if rem āplugs: [ home ]ā, users could still ārem hereā where āhereā is just not a top-lovel hidden directory (so, /home/user/my-rem-files is fine, /home/user/my-rem-files/.hidden is fine). Not having used rem before, this seemed like it might be a reasonable approach (it works by default and it works for the vast majority of users when using ārem hereā). If this isnāt the case, can you explain further?
Also, I hope you donāt misunderstand my questions as rejecting your request. Part of requesting classic confinement is understanding precisely why it is needed, making recommendations on how to run in strict mode where possible, and capturing when strict-mode doesnāt work for the application when not.
Ah, ok. Got you now! Indeed, with the āhomeā interface it should work how you described. But Iāve looked at https://snapcraft.io/docs/reference/interfaces, where it states āCan access non-hidden files in userās $HOMEā. So I came to another conclusionā¦
But another problem for rem is $PATH. Rem can be used to store commands and execute them later on. Think about rem like something like alias or make.
Iāll give you an example: Given I initialise in the directory $HOME/dev/myapp a local .rem file with rem here. And I will save a command in this directory with rem, and this command would be ādocker run ā¦ā. When running this command later on with (snap-packaged) rem, I would get following error:
exec: ādockerā: executable file not found in $PATH
Does $PATH consists for a running snap app only of /snap/bin/?
The āalias/makeā functionality is probably the reason you would need classic confinement, depending on how the application is written. You can see what PATH is set to be running:
$ snap run --shell rem
$ env|grep PATH
If the āremā command is the one doing the executing, then the command it is executing (in your example, ādocker runā¦ā) will be run under the confinement of āremā. Based on how you described the command (write a rem file to a dir, cd to that dir, run ārem hereā then it sounds l like rem finds the .rem files and executes stuff out of them). If this is true, there is no alternative to classic confinement at this time.
I can confirm, that with classic confinement it works like it should!
Usage example:
$ cd ~/dev/foo
$ rem here # creates ~/dev/foo/.rem
$ rem add ls -la # adds 'ls -la'
$ rem # list commands
0 ls -la
$ rem 0 # execute index 0
insgesamt 12
drwxr-xr-x 2 martin martin 4096 Aug 21 20:09 .
drwxrwxr-x 8 martin martin 4096 Aug 21 20:09 ..
-rw------- 1 martin martin 7 Aug 21 20:09 .rem
rem replaces its own process via https://golang.org/pkg/syscall/#Exec / execve with the one stored.
So are the requirements for a classic confinement met?
Can somebody please decide my question about the confinement of my app? Any answer welcome.
@mbo Iām sorry for the lack of feedback. This topic seems to have fallen through the cracks and we shouldnāt allow that to happen. Iām looking into rem right now and will provide more feedback shortly.
This is indeed a proper case where classic would be needed today, as the tool needs to be able to execute arbitrary commands in the local machine, with whatever permissions that the given command would have usually. We obviously canāt do that with strict confinement.
+1 from me for classic.
@jdstrand Can you please have a look into this again when you have a moment?
@niemeyer, per Process for reviewing classic confinement snaps, classic reviews are primarily handled by the snap advocacy team.
I agree this snap is a candidate for classic on technical terms and weāve sufficiently captured why it is required, but I donāt see where the advocacy team has vetted the publisher. As architect, if you feel the publisher is sufficiently vetted, please say so and Iāll grant the declaration. Otherwise, @evan, @Wimpress or @popey: can one of you work with the publisher following the agreed to process (does not necessarily have to happen in the forum) and communicate back in this topic that youāve vetted the publisher? At this point, Iāll be happy to grant the snap declaration.
Apologies for the delay @mbo. As youāre the upstream developer and this clearly needs access in arbitrary directories Iām +1 for this being classic.
A +1 from me as rem requires arbitrary access to files and directories and @mbo is the upstream developer of rem and has connected its GitHub repo to build.snapcraft.io.
Thank you @popey and @Wimpress. This looks to be for https://dashboard.snapcraft.io/dev/snaps/8217/. Iāve granted the snap declaration for classic. It is live now.
Thanks to everyone !