Above mentioned issue doesnot occur when snap is “classic” confined .
I have also discussed with @abeato and suggestion was to change this snap to classic confined.
Before working to change “lenovo-wwan-dpr” to classic confined and publishing it in “edge” channel, I would like to get feedback if its acceptable to do it or not?
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.
I have one of these but it doesn’t have a WWAN modem
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:
amurray@sec-focal-amd64:~$ mmcli -L
No modems were found
amurray@sec-focal-amd64:~$ sudo snap install lenovo-wwan-dpr
lenovo-wwan-dpr 1.0.2-wwan-dpr from Snap Linux Lenovo (lenovo-snap✓) installed
amurray@sec-focal-amd64:~$ mmcli -L
error: couldn't create manager: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 5 matched rules; type="method_call", sender=":1.93" (uid=1000 pid=2978 comm="mmcli -L " label="unconfined") interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" error name="(unset)" requested_reply="0" destination=":1.14" (uid=0 pid=581 comm="/usr/sbin/ModemManager " label="unconfined")
amurray@sec-focal-amd64:~$ systemctl status snap.lenovo-wwan-dpr.wwan-dpr.service
● snap.lenovo-wwan-dpr.wwan-dpr.service - Service for snap application lenovo-wwan-dpr.wwan-dpr
Loaded: loaded (/etc/systemd/system/snap.lenovo-wwan-dpr.wwan-dpr.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Mon 2022-05-09 21:25:54 ACST; 7s ago
Process: 2951 ExecStart=/usr/bin/snap run lenovo-wwan-dpr.wwan-dpr (code=exited, status=0/SUCCESS)
Main PID: 2951 (code=exited, status=0/SUCCESS)
May 09 21:25:54 sec-focal-amd64 systemd[1]: Starting Service for snap application lenovo-wwan-dpr.wwan-dpr...
May 09 21:25:54 sec-focal-amd64 DPR_wwan[2951]: get_product(): WWAN DPR functionality is not supported in this product
May 09 21:25:54 sec-focal-amd64 DPR_wwan[2951]: DPR and FCC unlock App is not supported by Lenovo now
May 09 21:25:54 sec-focal-amd64 systemd[1]: snap.lenovo-wwan-dpr.wwan-dpr.service: Succeeded.
May 09 21:25:54 sec-focal-amd64 systemd[1]: Finished Service for snap application lenovo-wwan-dpr.wwan-dpr.
(failed reverse-i-search)`de': systemctl status snap.lenovo-wwan-dpr.wwan-^Cr.service
amurray@sec-focal-amd64:~$ sudo dmesg | grep DENIED
[ 58.635782] audit: type=1400 audit(1652097205.734:41): apparmor="DENIED" operation="open" profile="snap.lenovo-wwan-dpr.wwan-dpr" name="/sys/devices/virtual/dmi/id/product_family" pid=1775 comm="DPR_wwan" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
ie there is only one AppArmor denial and 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:
amurray@sec-focal-amd64:~$ sudo mmcli -L
No modems were found
Also I don’t really see how making the snap classic would solve anything, since if I reinstall it in devmode then I still get the same error:
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.
Finally I even tested it as classic and it still didn’t work for me:
@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:
Ok .
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
Please can you provide more complete details on the errors you see since I am not able to reproduce this locally, otherwise I don’t think I can help you very easily.
@nitin_exclusively on the github page for that commit you can see that this exists in snapd versions 2.57.4 through to 2.57 - it looks like on Fedora snapd is still stuck at version 2.56.2 so it does not have this fix . Once a newer snapd is uploaded for Fedora then this will be available there too.
@mvo do you know if there are plans to update snapd in Fedora?
Hello @alexmurray, Sorry to bother you again .
I can see that fedora has 2.56.2 version but i have installed version 2.57.2 using “snap install snapd” But again same issue occur and i can see below log using “mmcli -L”
error: couldn’t create manager: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Sender is not authorized to send message
I think, i need to wait for fedora till it gets snapd version 2.57.1 or later .
But , i would like to know how snapd works in fedora like fedora has version 2.56.2 as default but user can install snapd again using "snap install snapd " and can see version as 2.57.2 using “snap list”, in this way does snapd has all related modification of 2.57.2 or it still have 2.56.2 in background ?