As per apparmor issue , “/dev/wwan0at1” is not accessible by snap . Hence , i have modified like below and it looks working .
Also , i need to connect like “snap connect lenovo-wwan-dpr:test”
Is this the correct way to solve this issue ? Also , do i need to request auto-connect for new plug “test” as mentioned above ?
Any information regarding this will be helpful.
Hi @nitin_exclusively - so it is possible to access /dev/wwan0at1 if your snap slots the modem-manager interface - however, this is really only designed for the modem-manager snap itself. Can you explain why your snap requires access to the wwan device directly? I recall it already plugs the modem-manager interface which gives it access to ModemManager (which in turn has raw access to the wwan device). Is this not sufficient for your snap? Thanks.
Device /dev/wwan0at1 is the generic AT interface and this will be passed from “lenovo-wwan-dpr” App to perform FCC unlock functionality . We are using “AT” interface to perform FCC unlock and connect to network, for some WWAN module.
I recall it already plugs the modem-manager interface which gives it access to ModemManager
Yes, we already plugs “modem-manager” plugs . I might be wrong , but i think “modem-manager” interface give access to “/dev/wwan0mbim0” as we had used this device for some modem and didnt get this issue but now when we pass “/dev/wwan0at1” then we get this access issue .
Snap interfaces can either be ‘plugged’ or ‘slotted’ - when slotting an interface this semantically maps to providing that interface to other snaps - and so when plugging an interface then you are connecting to the slot of another snap (or an implicit slot in the case of slots provided by the core snap/system).
Note I am only focussing on the AppArmor rules but the process is similar for seccomp and udev rules as well.
As such, we can see that /dev/wwan devices are only allowed access within the slot rules - https://github.com/snapcore/snapd/blob/fc63ca9480f93b261db0816e08db9246f976ccaf/interfaces/builtin/modem_manager.go#L64 - and so your snap will then instead need to slot this interface instead. However, given the semantics I described above, ideally then your snap would actually also ship modem-manager itself internally and provide a complete implementation of the modem-manager slot.
I am not certain what the best course of action is here - it doesn’t really feel right to slotmodem-manager as your snap is not trying to be a complete implementation of modem-manager on a system (and instead it uses the system installed ModemManager which does seem most appropriate).
Also for the case of just plug-ing modem-manager - whilst we can use system-files to grant AppArmor access to the device file in this case, this will not grant the appropriate udev rules for device to be visible within the snap’s device cgroup.
@mvo@pedronis@abeato@ogra any ideas on what might be most appropriate here? Am I missing something obvious (or non-obvious)?
@alexmurray Thank you for this information.
I got information regarding slot and i tried adding only ‘modem-manager’ slots in my snap but unfortunately , it did not fix this issue, maybe because we don’t have this modem-manager implementation in my snap.
I have tried using system-files as per example which i had shown earlier and this seems to fix the issue and its works fine. Hence ,for this issue, i would like to avoid shipping “modem-manager” from the snap.
May i know, if its acceptable to use system-files as below to fx this issue ?
no, system-files only allows access to actual files, not to devices, as alex said, it will miss the udev rules to make the device accessible inside the snaps cgroup …
not to devices, as alex said, miss the udev rules to make the device accessible inside the snaps cgroup
OK, Noted but i was just wondering, why i didn’t get any issue when i use “system-files” . I will do some more testing to find , if there is any issue regarding udev rules.
However, It will be helpful, if you can provide your suggestion to fix this issue ?
I have retested again using system-files and it works fine … It looks only access to file “/dev/wwan0at1” works … didnt face any issue regarding udev rules in test snap i.e stric confined which i have created for this .
@ogra@alexmurray Any comment regarding this will be helpful !! Thank you
@pmeulengracht Thank you for your comments !! I get it working only using system-files . But in this case i need to explicitly request approval for plug “test” like below :