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.
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).
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.
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:
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 ?
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.
The Process for reviewing classic confinement snaps does include vetting of the publisher by Canonical so this is already covered (ie we try and ensure the publisher is the upstream project OR is a proven trusted developer). Like I said above though, I think it is pretty clear that bat does not fit with the existing categories for classic confinement so for now I think we should park this request unless a snap architect can weigh in and suggest an expansion to the supported use-cases for classic confinement that would fit with bat - ping @pedronis
I did talk with the owner of this and he is not ready to maintain this package on his own. Due to the so many issues, we removed this package from the store for the better good.
.