Classic confinement request: batcat

Greetings @review-team, I am independent developer who loves to develop and create snap packages. I create snap package form GitHub repo: https://github.com/sharkdp/bat.

In explanation of the package, bat is a modified version of the Linux command cat. Some of the interesting features of bat is syntax highlighting, git integration and automatic paging. But just like cat command, main purpose of this is displaying file in terminal. Most users are trying to access file that resides in a root directory and without classic confinement, snap gives an error. In addition, users have been already filed an issues on GitHub and reach of the package is decreased.

More Information,
Official GitHub Repo: https://github.com/sharkdp/bat
Snap-package GitHub Repo: https://github.com/purveshpatel511/batwing
Snapstore URL: https://snapcraft.io/batcat/

You can also check out some of the issue here to understand problem more clearly,


So, i request you guys to approve this.

Thanks.

Hey @badpurvesh11,

As per the Process for reviewing classic confinement snaps, access to arbitrary files on the system is not typically a justification to grant classic confinement. Please remember that classic confinement snaps run without restrictions, and thus use of classic confinement effectively grants device ownership to the snap.

You could get access to the /tmp directory by using the system-files interface (like this snap does), or you could even plug personal-files or removable-media if needed as well (I see you are already plugging home).

@badpurvesh11 ping, could you try the suggested interfaces? Thanks!

Hi @emitorino, Thanks for your concern.

After your suggestion, i tried to use personal-files interface and read some forum discussion of another snap that might has similar problem that i have.

Considering this thread, i understand that i have to write separate pulgs of personal-file interface for all the hidden files i want to access. But here’s the problem, snap batcat is used to display any kind of text file(hidden as well as non-hidden) in terminal located anywhere in $HOME directory. So, there might be more than one hidden file created by different application and user himself that i would be not aware of it. Concluding, there is no possible way for me to write separate interfaces for files that i am not aware of it.

Further explanation of problem, let’s say i want to display .gitignore file. But maybe there are multiple gitignore files exist at different projects location, thus, personal-file interface is not useful here.

So, is there any interface or any bypass trick that let snap access all the hidden files resides in user’s $HOME directory.

Thank you :blush:.

That’s correct. Yes.

Unfortunately no. But @alexmurray, @pedronis: do you think this request could fall under the supported category of text editors?

The supported category we have at the moment is IDEs, not text editors as IDEs generally need to invoke external commands like compilers and get access to header files from the host system etc. Whilst text editors just edit files. So either way personally I don’t think this fits in the existing categories for classic confinement.

I think perhaps if folks want to use bat to access arbitrary files, they could write a shell function that does something like the following untested off-the-top-of-my-head idea:

function bat() {
  cp $* ~/snap/bat/common
  /snap/bin/bat ~/snap/bat/common/$*
  rm ~/snap/bat/common/$*
}

which would then allow it to access arbitrary files just by placing them inside $SNAP_USER_COMMON.

This imposes a requirement of the end user to understand that the cat alternative they’ve just installed to have nice syntax highlighted display of their files can’t be used with their own dot files because of the package manager used.

They then have to do the work to implement the workaround, and do it correctly, again, simply to display their own files with bat.

If they’d installed bat via apt, then there’s no extra requirements imposed on the end user that just wants to use the application and get on with their day.

I’d argue that if the snap confinement mechanism does not yet have the facility to grant read-only access to the files that a user has at least read permission on, regardless of where they are on the system or their name, then it makes sense to grant bat classic confinement.

Otherwise the snap package format is making it hard for itself to proliferate.

Agree on this. Maybe SnapCraft’s folks should give a thought to release a read-only plugin for snaps.
Plugin, that can access any file on system in read-only mode. This shall give a bit more flexibility to snap developers.

would you feel comfortable to give some random snap from evildude256 read access to your browser cache, passwords and history ? to your emails, account data and your sensible online banking info ? .

… so that a hidden function in the snap can upload all of it to a powerful de-cyphering server ?

Hey @ogra, you got me there. Did not think about this. Still wish that we can do something for these kind of problems.

1 Like

Obviously not.

But part of the reason for the snap store being as it is, a single trustworthy source of snaps, is that Canonical are able to make the call on whether a snap is trustworthy and ok to be granted classic confinement, or even wider than usual confined permissions such as a hypothetical read-only permission.

I personally would be happy if one of the requirements for classic confinement was that the snap was published by the same person/organisation that authored the software. That wouldn’t help @badpurvesh11’s case here, but could help Canonical grant more software classic confinement status while snap confinement permissions and abilities mature.