The issue with accessing modem-manager over dbus should be fixed with snapd 2.55.3 which only went stable today - can you please retest? I am pretty sure this issue can be solved without resorting to classic confinement but more information is likely going to be needed. Can you also please make sure to send through any denials which you see in dmesg?
Hello @alexmurray@review-team, I am ready to update snap package to change it from "strict’ to “classic” confined . it will be helpful if you can update your comment regarding this and whether i can publish it or not. Thank you
As per the Process for reviewing classic confinement snaps you need to describe not only why you believe classic confinement is required but also then detail which of the criteria for classic confinement your snap fits within. Then we need to determine if the snap fits within one of the supported categories for classic confinement.
However, I am a bit confused here about the errors you mention with strict confinement for your snap - can you provide details for how this can be reproduced and I can try and look into it - since the error mentions the process is unconfined which seems odd - is mmcli part of the lenovo-wwan-dpr snap? Can you please try and explain more what the setup of your snap is and what it is doing and I think we should be able to get it working under strict confinement.
Ah indeed - good spotting @jamesh - so those rules should specify path=/org/freedesktop/ModemManager1 rather than the existing path=/org/freedesktop - perhaps that may be enough - but if more info could be provided as to how to reproduce these errors then I can try and validate this manually if needed.
@alexmurray First of all thank you for checking this and your great support.
This feature is related to WWAN modem and i haven’t tried in non-WWAN system. its good that you can see error.
So I don’t think this is an issue with the snap - I just tried installing this snap and I get the same error but it is not due to AppArmor denying anything:
Sorry but i really think this issue is related to snap as this issue doesnot occur if i create “deb” package for this app and yes, this is not related to AppArmor as i have also not seen AppArmor issue.
it is not for any DBus access - instead I suspect this is DBus policy itself - since if we run mmcli under root then it works:
So I can’t see any good evidence that this is related to AppArmor - it could easily be due to the snapd dbus policy but that is a bigger issue I think.
I have same understanding that this is not related to AppArmor instead its related to dbus policy.
So I really can’t see how classic confinement is going to solve this - can you please provide more info?
I have changed confinement as “classic” in snapcraft.yaml file and then given command “snap install --dangerous --classic lenovo*.snap” . In this scenario , i didnot get any error and snap works perfectly OK. But , if i changed confinement to “strict” then this issue is occurred. I am not sure what difference it will make by simply giving command --classic but keeping confinement as “strict” in snapcraft.yaml file . Will it be same behavior? I will also try it from my side.
Please ignore above above comment as i found out that you have changed yaml file from strict to classic while testing classic. I have again tried it on my WWAN supported system and it works using classic snap .
please check below steps and result:
Confinement is strict in snapcraft.yaml file
Install modified snap -
Command - snap install --dangerous lenovo*.snap (This is updated snap which i have not released now)
“mmcli -L” gives error , when not in root and it break gnome network settings