Request for classic confinement: sas2ircu

There are hardware monitoring tools that are published by the vendors in binary format only. Some of the binaries require a level of access not provided by plugs such as hardware-observe or system-observe. This is the case of the sas2ircu binary published by Huawei under “FusionServer Tools InfoCollect” archive.

For such reason, I request this snap to be allowed as non-confined. When the snap is in strict confinement, binary always returns code 1.

Other snaps I’m working on are sas3ircu and megacli.

Thank you,
-Alvaro.

PS: https://dashboard.snapcraft.io/snaps/sas2ircu/revisions/5/feedback/

What specific accesses are required?

By checking sas2ircu syscalls, I see that the access to /dev/mpt2ctl is not working as expected.

See the output of “strace sas2ircu list” via a snap with confinement “classic” and “strict”, respectively:
http://people.canonical.com/~aluria/sas2ircu.list.classic
http://people.canonical.com/~aluria/sas2ircu.list.strict

Per https://linux.die.net/man/8/smp_utils, /dev/mpt2ctl is needed for the MPT fusion SAS. Looking at the classic strace, this seems to:

  • need /dev/mpt2ctl and /dev/mpt2ctl_wd added to the device cgroup
  • add /dev/mpt2ctl{,_wd} rw, to the apparmor policy

Beyond that, it is just ioctls that are required. An interface implementing this would be easy enough, but it isn’t clear to me what should be in the interface, and therefore, what it should be called. We have hardware-observe which allows reading from various hardware, so hardware-control seems like an option, but with a name like that, we’d eventually add other accesses to it and while grouping reads of hardware seems somewhat ok, grouping writes feels wrong (we did just add a new cpu-control recently after all). I think I’m leaning towards something related to ‘disks’, eg, disks-control. Perhaps in it we would allow access to block devices, as is suggested in Classic Confinement Request for the wimlib Snap and it could also cover smartctl and hdparm (Snap interface to run smartctl) along with /dev/mpt2ctl.

@pedronis, @niemeyer - thoughts?

2 Likes

There is probably a better name for this. Perhaps block-device-control

I don’t think we should conflate basic read/write access to (some) block-devices, with control over params etc. It still feels like we should have a more basic block-devices interface as well.

@pedronis - block-devices doesn’t fit our current pattern. Perhaps, block-device-control? what we you suggest for smartctl, hdparm, and sas2ircu?

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.

@jdstrand I’m referring to this discussion:

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.

  1. https://dashboard.snapcraft.io/snaps/sas2ircu/revisions/5/feedback/

@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?

FYI: https://github.com/snapcore/snapd/pull/6427

This is now in 2.37.1, which is in the stable channel.