The symlink and choice files are not the issue. When rebasing the change to the LTS I did not alter this call:
---> + priv = polkit_backend_action_pool_get_instance_private (pool); <--- which was introduced upstream on 2024-05-09 (so not in Noble or Oracular) by eafbf7d Fix G_TYPE_INSTANCE_GET_PRIVATE deprecation warnings Although the code compiles without warning about it, the ensure_all_files gets junk. Sticking to ---> + priv = POLKIT_BACKEND_ACTION_POOL_GET_PRIVATE (pool); <--- fixes the problem. ** Patch added: "noble-.1:.2.diff" https://bugs.launchpad.net/bugs/2089145/+attachment/5841525/+files/noble-.1%3A.2.diff ** Patch added: "oracular-.1:.2.diff" https://bugs.launchpad.net/bugs/2089145/+attachment/5841526/+files/oracular-.1%3A.2.diff ** Description changed: Hey! I would like to request a SRU of the following upstream PR for Noble. https://github.com/polkit-org/polkit/pull/499 I have applied this to ubuntu/noble-updates and produced a new patch that is attached with identical changes. The PR does not apply directly due to mismatch in a couple of lines that differ from upstream. - [ Impact ] On Ubuntu Core we've had not historically carried polkit before, it has only recently been decided to include polkit into the Core24 base (and future bases), so this has not been an issue up until now. The decision changed as Core Desktop is moving its architecture to using the official core24 base snap as their base for all the desktop snaps. Core Desktop needs to use polkit for the desktop/user environment, but this brings us to this request. The polkit version currently in Noble does only support reading actions from /usr/share/polkit-1/actions, but this is a protected read-only path on Ubuntu Core. We could change this and map this path into the writable area, but this would bring us into transition issues when/if people want to migrate from core24 to core26 (i.e remodelling), where newer polkit supports reading actions from /etc. This would leave files in a weird state moving away from mapping that path, to the more appropriate /etc. The more sustainable plan is to SRU the mentioned patch, allowing polkit to read actions from /etc, and would provide us with more consistent behaviour moving forward with newer bases, that may contain newer polkit versions that naturally support /etc. + [ Test plan ] + + 1. Install the package from proposed. + 2. If no authentication agent is running, start one: /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent + 3. Execute 'firewall-cmd --list-services'. + + A dialogue should appear, input your password and see that command + returns normally, in a unaltered setup it says dhcpv6-client ssh. [ Where problems could occur ] - * Think about what the upload changes in the software. Imagine the - change is wrong or breaks something else: how would this show up? + * Think about what the upload changes in the software. Imagine the + change is wrong or breaks something else: how would this show up? Since this is about loading actions, any issues resulting from this change should show up immediately by identifying whether the actions are loaded. - * It is assumed that any SRU candidate patch is well-tested before - upload and has a low overall risk of regression, but it's important - to make the effort to think about what ''could'' happen in the event - of a regression. + * It is assumed that any SRU candidate patch is well-tested before + upload and has a low overall risk of regression, but it's important + to make the effort to think about what ''could'' happen in the event + of a regression. In case of a regression, actions from /usr/share/polkit-1/actions would not be loaded either. - * This must never be "None" or "Low", or entirely an argument as to why - your upload is low risk. + * This must never be "None" or "Low", or entirely an argument as to why + your upload is low risk. I would indicate this is a 'Medium' in risk, as this code change is very isolated. There is no functional or behavioural changes. This is specifically the places we load configuration / actions from. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to policykit-1 in Ubuntu. https://bugs.launchpad.net/bugs/2089145 Title: Backport patch to read actions from /etc and /run Status in policykit-1 package in Ubuntu: Fix Released Status in policykit-1 source package in Noble: Fix Committed Status in policykit-1 source package in Oracular: Fix Committed Bug description: Hey! I would like to request a SRU of the following upstream PR for Noble. https://github.com/polkit-org/polkit/pull/499 I have applied this to ubuntu/noble-updates and produced a new patch that is attached with identical changes. The PR does not apply directly due to mismatch in a couple of lines that differ from upstream. [ Impact ] On Ubuntu Core we've had not historically carried polkit before, it has only recently been decided to include polkit into the Core24 base (and future bases), so this has not been an issue up until now. The decision changed as Core Desktop is moving its architecture to using the official core24 base snap as their base for all the desktop snaps. Core Desktop needs to use polkit for the desktop/user environment, but this brings us to this request. The polkit version currently in Noble does only support reading actions from /usr/share/polkit-1/actions, but this is a protected read-only path on Ubuntu Core. We could change this and map this path into the writable area, but this would bring us into transition issues when/if people want to migrate from core24 to core26 (i.e remodelling), where newer polkit supports reading actions from /etc. This would leave files in a weird state moving away from mapping that path, to the more appropriate /etc. The more sustainable plan is to SRU the mentioned patch, allowing polkit to read actions from /etc, and would provide us with more consistent behaviour moving forward with newer bases, that may contain newer polkit versions that naturally support /etc. [ Test plan ] 1. Install the package from proposed. 2. If no authentication agent is running, start one: /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent 3. Execute 'firewall-cmd --list-services'. A dialogue should appear, input your password and see that command returns normally, in a unaltered setup it says dhcpv6-client ssh. [ Where problems could occur ] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? Since this is about loading actions, any issues resulting from this change should show up immediately by identifying whether the actions are loaded. * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. In case of a regression, actions from /usr/share/polkit-1/actions would not be loaded either. * This must never be "None" or "Low", or entirely an argument as to why your upload is low risk. I would indicate this is a 'Medium' in risk, as this code change is very isolated. There is no functional or behavioural changes. This is specifically the places we load configuration / actions from. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/2089145/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
