Sorry, I’m arguing that a block-device-control is not the answer to something like wimlib that only needs to read or write block devices under /dev/* , we had a silimar discussion about fwupd where Gustavo proposed block-devices.
FYI, this same issue applies to other snaps I was about to work on:
- sas3ircu needs access to /dev/mpt3ctl
- megacli (MegaCLI64 binary) needs access to /dev/megaraid_sas_ioctl_node
See similar strace files for comparison:
http://people.canonical.com/~aluria/sas3ircu.list.classic
http://people.canonical.com/~aluria/sas3ircu.list.strict
http://people.canonical.com/~aluria/megacli.LDinfo.LALL.NoLog.classic
http://people.canonical.com/~aluria/megacli.LDinfo.LALL.NoLog.strict
Cheers,
-Alvaro.
1 Like
@pedronis - I understood what you meant and that you wanted two separate interfaces, one with access to block devices and one with accesses for sas2ircu, smartctl and hdparm. My question was about naming the interfaces. @niemeyer said "something like block-devices" for the former, but my point is that “block-devices” doesn’t fit our current naming pattern. If you prefer block-devices, I’m not opposed to that. What should the 2nd interface (the one for smartctl, hdparm and sas2ircu) be named? harddrive-control? disks-control? something else?
can you explain why you think it doesn’t fit the current patterns? notice that actually some our singular names are problematic with hindsight like “camera” for an interface that let access all cameras.
It depends on what is in the interface of course. If we had smartctl in there, I would strongly argue for ‘-control’, but that will now be in a different interface. Since it will just be block devices, holding up the camera interface as an interface (though it should be plural like you said) supports that ‘block-devices’ is suitable. There is a good deal of ‘control’ granted with this interface, since one can control partitions, filesystems, data, etc, but the simple ‘block-devices’ is clear enough I suppose (I did say I wasn’t opposed to it).
Hi @jdstrand,
What would be the best approach while support for “block-devices” is being discussed/worked out? Would it be possible to get [1] approved (in classic mode) until this is supported so I could push a newer version in strict mode when such interface is available?
I must admit I’m not sure if a snap can be refreshed and moved from classic to strict automatically, just by updating the revision (and having such revision built using strict confinement).
Thank you,
-Alvaro.
@aluria - the block-devices interface (or whatever it will be named) could be implemented quickly. To answer your question, my understanding is upgrades from classic to strict is supported but the other way around is not (less strict to more strict is ok).
@pedronis - can you comment on a finalized name? In the meantime, what do you think about allowing classic for now?
I think “block-devices” still seems a good working name, we can revisit that when we have a PR and is clearer what is actually granted access to.
Hi @pedronis,
Is the ETA for having this new interface available short or could I ask for classic snaps approval for megacli, sas2ircu, sas3ircu snaps in the meantime?
Thank you,
-Alvaro.
I’ll try to have this in the next snapd release but not sure of that timing. @pedronis should classic for the short term should be granted?
This is now in 2.37.1, which is in the stable channel.
Is it safe to add a new interface to the app? How old snapd installations will handle it?
Thank you.
IIRC snapd will error and refuse to install the snap if it has an interface assertion it doesn’t recognize.
@jdstrand @zyga-snapd @mborzecki
I.e. the new-version app (with added interface) will not be able to install/run on old versions of Linux distributions?
What if this interface will not be auto-connected?
Thank you.
block-devices is in 2.37 which is now everywhere. You might be interested in the “little known feature” @zyga-snapd mentioned in Is snapd forward compatible with new app interfaces? (ie, ‘assumes’).
As for auto-connection, please create a new forum topic and follow Process for aliases, auto-connections and tracks
1 Like
Do I need sudo to use block-devices interface?
Tried w/o sudo and smartctl reported:
Smartctl open device: /dev/sda failed: Permission denied
With sudo all is Ok:
sudo smartctl -x /dev/sda # smartctl is a snap here with embedded smartmontools
I.e. I can’t use smartctl when user clicks on a Launch button in Ubuntu Software?
Thank you.
There is a list of permissions to run smartctl: https://medium.com/opsops/why-smartctl-could-not-be-run-without-root-7ea0583b1323
What is still missing when I connect block-devices interface (smartctl still reports Permission denied w/o sudo)?
Thank you.
This isn’t coming from snapd but traditional permissions and capabilities. Yes, you need to be root to use smartctl.
1 Like