This is a snap for the trash-cli tool which is a command-line interface to FreeDesktop.org Trash. This tool is often considered a safer alternative to rm command but in order to work it does require access to whatever files the user passes to it (assuming the user has permissions to write to those files of course) and be able to move them to the $topdir/.Trash/$uid or $topdir/.Trash-$uid folder where $topdir is the top directory of the volume that the file is on (and create that folder if it doesn’t already exist and the user has perms to create such folder).
This follows the FreeDesktop.org Trash specification that can be read here: https://specifications.freedesktop.org/trash-spec/trashspec-latest.html
I’d like to request classic confinement as I don’t think snap would otherwise have any way to access “arbitrary” files (arbitrary is in quotes because they are files that are passed to the cli by the user, the tool doesn’t just move random files around 
) on the system. I haven’t seen any interface that would allow interfacing with Trash (moving things to it, emptying it, listing files in it, restoring from it) and moving arbitrary files to it like that.
Please also note that this tool is not only useful in desktop environments but also on servers (clearly you wouldn’t want to accidentally delete things there) so if this use case were to be accommodated in the future, it would be great if it didn’t require services that are typically only found on the desktop systems with a display server.
So for access to ~/.Trash you can use personal-files - for other media, removable-media should be sufficient. As such I do not think this should require classic confinement (nor based on the current evidence does it appear to fit within one of the supported categories for classic confinement as per Process for reviewing classic confinement snaps).
This tool is supposed to be able to move the files you pass to it to the Trash folder so only having access to the Trash folders isn’t particularly useful (aside from being able to clean the trash which is only a part of tool’s functionality). The tool has to actually have permissions to move files specified by the user to and out of Trash and those files can be anywhere in the filesystem depending on what the user wants to put into trash.
Additionally, per the specification Trash folders are made per volume so personal-files and removable-media aren’t enough to have access to all relevant Trash folders - e.g. it’s common to have / and /home (and sometimes more, e.g. /var, /data, /tmp, or other somewhat less common setups) as separate partitions/mounts. removable-media only grants access to /media, /run/media, and /mnt.
As per the Process for reviewing classic confinement snaps it is not sufficient to just outline why a snap cannot work with strict confinement for it to then be granted classic - it also needs to fit within one of the supported categories for classic confinement. Can you please review that documentation and provide more information? Thanks.
Process
- the publisher makes the request for classic confinement in the forum using the store-requests category
- the technical reasons for why the snap uses classic confinement are gathered in the forum post and captured for potential future snapd improvements. The technical requirements will be reviewed by the security team and/or an architect
- the advocacy team, reviewers team and/or architects participate in vetting the snap/publisher
- once the publisher has been vetted, the technical reasons are captured and the request is approved, a store reviewer will issue a snap declaration for the snap and add a comment to the store, giving the URL to the forum post
I followed the above process and explained the technical requirements for why classic confinement is needed.
Known categories
Classic requests generally fall under a number of categories. Below lists categories that developers may consult for things that are known to be allowed/disallowed use of classic confinement. reviewers may consult these lists when processing classic requests. If something falls outside of these lists, then the requirements must be gathered by a senior reviewer and discussed with an architect (after which, it can be added to the lists).
[Emphasis mine] The above made me think that I don’t have to fall into the known categories to be able to request classic confinement. Based on the currently published list, it does not seem that I fall into any known supported categories and I also don’t think I fall into any known unsupported categories though the way some of them are written makes them open to interpretation I guess.
Yes that is true, but adding new categories for classic confinement is not a trivial process - snap architects are in very limited supply so this can take quite a while to get reviewed etc.
Also whilst I agree that strict confinement will not allow these other use-cases (e.g. volumes mounted under /var etc) I would suggest this is a much less likely use-case in practice than /home etc (which is covered by home, removable-media and personal-files). As such, your snap should be able to work for most use-cases that most users will have via these existing interfaces. Snap confinement is known to have limitations and cannot support all possible different application use-cases, however it does support the vast majority that most users will encounter.
So I would suggest you still pursue strict confinement with these interfaces instead of classic.
To be honest, I made this snap primarily for my own use, and I do use this application to remove files from folders such as /tmp, /etc, /opt using the root volume’s /.Trash folder so I’m going to just withdraw my classic confinement request. On my system, I have instead settled for using a global install of this package using pipx which is probably better suited for an application that cannot reasonably be confined anyway.
Thank you for taking the time to review my request.
Ok no worries - thanks, I will remove this request from our queue.
