I changed clamtk-rs confinement to strict, no need for classic approval.
it now bundles clamav.
it seems to require sudo snap connect clamtk-rs:mount-observe to avoid a GTK warning.
Could someone review the snap?
This request has been added to the queue for review by the @reviewers team.
Hi @lapisdecor,
To make the review of your request easier, please use the following template to provide all the required details and also include any other information that may be relevant:
name: name of the snap
description: description of the snap
snapcraft: link to snapcraft.yaml if publicly available
upstream: link to the upstream repository if open-source or ‘PRIVATE’ otherwise
upstream-relation: relation of the snap publisher with the upstream
plugs:
<interface-name>:
interface: [optional] one of https://snapcraft.io/docs/reference/interfaces/
attributes: [optional] interface attributes if any
request-type: installation | manual-connection | auto-connection
reasoning: why is this interface needed
...
slots:
<interface-name>:
interface: [optional] one of https://snapcraft.io/docs/reference/interfaces/
attributes: [optional] interface attributes if any
request-type: installation | manual-connection | auto-connection
reasoning: why is this interface needed
...
For quick reference, you can also find this info - plus an example - right when creating a ‘New Topic’ under the privileged-interfaces subcategory. Editing this forum post with new information is perfectly fine.
Thanks
name: clamtk-rs
description:
Clamtk-rs is a lightweight, user-friendly graphical frontend for ClamAV
written in Rust with GTK4. It provides on-demand virus scanning, virus
signature updates (freshclam), a quarantine manager, scan history and
detailed scan settings.
The snap bundles its own ClamAV (clamscan and freshclam) and runs under
strict confinement. Virus definitions are downloaded automatically on the
first scan and can be refreshed from the Update Signatures page.
snapcraft: https://github.com/lapisdecor/clamtk-rs/blob/master/snap/snapcraft.yaml
upstream: https://github.com/lapisdecor/clamtk-rs
upstream-relation: developer
plugs:
mount-observe:
request-type: auto-connection
reasoning: when scanning a dir I get this warning:
(clamtk-rs:33132): GLib-GIO-WARNING **: 12:15:42.804: Error creating IO channel for /proc/self/mountinfo: Permission denied (g-file-error-quark, 2)
removable-media:
request-type: auto-connection
reasoning: needed so user can scan external drives for virus
slots:
dbus-svc:
interface: dbus
bus: session
name: com.gatochalupa.clamtk-rs
request-type: auto-connection
reasoning: dbus-svc block grants the snap the right to claim com.gatochalupa.clamtk-rs on the session bus
I edited the template, I think it’s ok now, please let me know if it’s not ok.
Thanks.
Hi @lapisdecor,
Looking at the denial message: (clamtk-rs:33132): GLib-GIO-WARNING **: 12:15:42.804: Error creating IO channel for /proc/self/mountinfo: Permission denied (g-file-error-quark, 2) does not look like a fatal warning and should not block the execution of the program. If that is the case, this can be ignored and access to mount-observe is not needed. Please let me know otherwise.
Regarding removable-media, it is a very sensitive interface and reserved for special cases only. Plus I would not say that scanning external drives for virus is the core functionality of clamtk-rs, which makes it non-eligible for this interface.
I have several disks on my computer where I do backups and I use clamtk-rs to scan them (they are not mounted by default) that’s why I used removable-media. But I’m ok with the decision, people will only scan the main disk.
I will change my snapcraft.yaml accordingly. What about the slot? Should I keep it?
I have changed clamtk-rs snapcraft.yaml to meet your requirements (kept the slot) but I think the snap still needs to be reviewed and approved in order to be published. Thanks in advance.
Hey
On the slot, yes, keep it. A session-bus slot claiming your own well-known name com.gatochalupa.clamtk-rs is routine and low-sensitivity, it’s just the app owning its name on the session bus, properly namespaced to your domain. Granted, no concerns.
On removable-media, one clarification so you don’t lose a feature you actually want. The decision was against auto-connection, not against the interface entirely. removable-media allows manual connection by default, so you can keep external and backup-drive scanning: users who want it just run snap connect clamtk-rs:removable-media once. For an antivirus tool that’s a legitimate use I feel, so rather than dropping it to “main disk only,” I would suggest keeping the plug in the yaml (as a plain plug, not an auto-connect request) and documenting the one-line connect command.
On mount-observe, agreed it is not needed
So, +1 from my end on manual-connection to removable-media and the dbus slot as declared,
thanks
Don’t I need mount-observe to see the external drives? I was trying to check this out but I’m on hollidays on a laptop with fedora and no external drives to test.
I dont think so, the two are separate. Seeing and scanning the files on an external drive comes from removable-media, which grants access to the mount points under /media, /run/media and /mnt where drives are mounted. mount-observe is different: it only grants read access to mount metadata (/proc/self/mountinfo, the mount table), i.e. what is mounted where, not the contents. So I dont think it is helpful in your case. but feel free to correct me
You are right but this is the difference between the user seeing directly the external drives in file open (under other locations) or having to navigate to /run/media/user/drive (which is not intuitive for regular users).
name: clamtk-rs
description:
Clamtk-rs is a lightweight, user-friendly graphical frontend for ClamAV
written in Rust with GTK4. It provides on-demand virus scanning, virus
signature updates (freshclam), a quarantine manager, scan history and
detailed scan settings.
The snap bundles its own ClamAV (clamscan and freshclam) and runs under
strict confinement. Virus definitions are downloaded automatically on the
first scan and can be refreshed from the Update Signatures page.
snapcraft: https://github.com/lapisdecor/clamtk-rs/blob/master/snap/snapcraft.yaml
upstream: https://github.com/lapisdecor/clamtk-rs
upstream-relation: developer
plugs:
mount-observe:
request-type: manual-connection
reasoning: needed so users can see external drives in "Other places" in nautilus
removable-media:
request-type: manual-connection
reasoning: needed so user can scan external drives for virus
slots:
dbus-svc:
interface: dbus
bus: session
name: com.gatochalupa.clamtk-rs
request-type: auto-connection
reasoning: dbus-svc block grants the snap the right to claim com.gatochalupa.clamtk-rs on the session bus
Hey @lapisdecor
I agree mount-observe is about making the drives easier to find in the dialog. This is a convenience rather than a requirement: with removable-media alone, scanning external drives fully works, but as a discoverability improvement it should be a plain/manual plug matching removable-media, not an auto-connect, a user connecting removable-media to scan a drive can connect mount-observe in the same step.
+1 for the manual-connection of the mount-observe plug too
I still have one problem though, in order to move virus to quarantine and remove the virus, I need permissions outside the sandbox.
This is a bigger problem if I do a full system scan: if a virus is found on some system file or dir I need to move that file to quarantine if the user chooses to do so, which means removing it from a system dir and moving it to the quarantine folder. For that I would need root permission.
Since snaps are sandboxed and I can’t use pkexec I have no idea how to achieve this without disabling the quarantine part of the application, specially in a strict confinement.
Any help on this matter would be awesome. Thanks in advance.
I think I made a partial solution for the above problem.
so it will be manual mount-observe and manual removable-media and it will display a dialog with a command to copy paste to terminal if permissions are required to move the virus.
Hi @lapisdecor,
Given the confined nature of the snap, I also think displaying command to copy paste to the terminal is a good idea.
+1 from my side as well to grant manual-connection to mount-observe and removable-media interfaces.
Hi @lapisdecor
Removable-media is a very sensitive interface and requires publisher vetting before I can grant access to the interface. I’ll DM you soon to start with the publisher vetting.
Hi @lapisdecor,
You should be able to use manual-connection for both of the interfaces without an approval from us and publisher vetting is also not required. You can safely ignore my message regarding publisher vetting. I am extremely sorry for the mix up.
No problem. I didn’t do anything yet. I can’t publish the snap without a review though… Thank you for all the support.