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.
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
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!
$ 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
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?
@evan - can you or a member of your team take a look at this?
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.