[Touch-packages] [Bug 1997553] Re: network-manager fails to trigger dispatcher scripts with action dhcp4-change when dhcp lease is renewed
OK. I'll report this upstream. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1997553 Title: network-manager fails to trigger dispatcher scripts with action dhcp4-change when dhcp lease is renewed Status in network-manager package in Ubuntu: Confirmed Bug description: We rely on network-manager dispatcher scripts on our desktop and laptop computers. The dispatcher scripts are used to update DNS records with nsupdate when the dhcp lease is renewed. With jammy this is not working anymore. It seems that dispatcher scripts are run only when the interface comes up (with action 'up') and with the initial dhcp lease (with action 'dhcp4-change'), but when the lease is renewed, the dispatcher scripts are not run with any action. The only action the dispatcher scripts are run regularly with is 'connectivity-change', which seems to occur twice in a row every few hours. I have made a simple script to log how the dispatcher scripts are run: /etc/NetworkManager/dispatcher.d/99-test: #!/bin/bash PATH='/bin:/sbin:/usr/bin:/usr/sbin' echo $(date) 0: $0 IFACE: $1 ACTION: $2 >> /tmp/nm.log This script proves that action 'dhcp4-change' only occurs when I manually restart NetworkManager.service or unplug and replug the ethernet cable. network-manager version: 1.36.6-0ubuntu2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1997553/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1997553] Re: network-manager fails to trigger dispatcher scripts with action dhcp4-change when dhcp lease is renewed
** Description changed: We rely on network-manager dispatcher scripts on our desktop and laptop computers. The dispatcher scripts are used to update DNS records with nsupdate when the dhcp lease is renewed. With jammy this is not working anymore. It seems that dispatcher scripts are run only when the interface comes up (with action 'up') and with the initial dhcp lease (with action 'dhcp4-change'), but when the lease is renewed, the dispatcher scripts are not run with any action. The only action the dispatcher scripts are run regularly with is 'connectivity- change', which seems to occur twice in a row every few hours. I have made a simple script to log how the dispatcher scripts are run: - /etc/NetworkManager/dispatcher.d/99-test: + /etc/NetworkManager/dispatcher.d/99-test: #!/bin/bash PATH='/bin:/sbin:/usr/bin:/usr/sbin' echo $(date) 0: $0 IFACE: $1 ACTION: $2 >> /tmp/nm.log + This script proves that action 'dhcp4-change' only occurs when I + manually restart NetworkManager.service or unplug and replug the + ethernet cable. - This script proves that action 'dhcp4-change' only occurs when I manually restart NetworkManager.service or unplug and replug the ethernet cable. + + network-manager version: 1.36.6-0ubuntu2 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1997553 Title: network-manager fails to trigger dispatcher scripts with action dhcp4-change when dhcp lease is renewed Status in network-manager package in Ubuntu: Confirmed Bug description: We rely on network-manager dispatcher scripts on our desktop and laptop computers. The dispatcher scripts are used to update DNS records with nsupdate when the dhcp lease is renewed. With jammy this is not working anymore. It seems that dispatcher scripts are run only when the interface comes up (with action 'up') and with the initial dhcp lease (with action 'dhcp4-change'), but when the lease is renewed, the dispatcher scripts are not run with any action. The only action the dispatcher scripts are run regularly with is 'connectivity-change', which seems to occur twice in a row every few hours. I have made a simple script to log how the dispatcher scripts are run: /etc/NetworkManager/dispatcher.d/99-test: #!/bin/bash PATH='/bin:/sbin:/usr/bin:/usr/sbin' echo $(date) 0: $0 IFACE: $1 ACTION: $2 >> /tmp/nm.log This script proves that action 'dhcp4-change' only occurs when I manually restart NetworkManager.service or unplug and replug the ethernet cable. network-manager version: 1.36.6-0ubuntu2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1997553/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1997553] [NEW] network-manager fails to trigger dispatcher scripts with action dhcp4-change when dhcp lease is renewed
Public bug reported: We rely on network-manager dispatcher scripts on our desktop and laptop computers. The dispatcher scripts are used to update DNS records with nsupdate when the dhcp lease is renewed. With jammy this is not working anymore. It seems that dispatcher scripts are run only when the interface comes up (with action 'up') and with the initial dhcp lease (with action 'dhcp4-change'), but when the lease is renewed, the dispatcher scripts are not run with any action. The only action the dispatcher scripts are run regularly with is 'connectivity- change', which seems to occur twice in a row every few hours. I have made a simple script to log how the dispatcher scripts are run: /etc/NetworkManager/dispatcher.d/99-test: #!/bin/bash PATH='/bin:/sbin:/usr/bin:/usr/sbin' echo $(date) 0: $0 IFACE: $1 ACTION: $2 >> /tmp/nm.log This script proves that action 'dhcp4-change' only occurs when I manually restart NetworkManager.service or unplug and replug the ethernet cable. ** Affects: network-manager (Ubuntu) Importance: Undecided Status: Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1997553 Title: network-manager fails to trigger dispatcher scripts with action dhcp4-change when dhcp lease is renewed Status in network-manager package in Ubuntu: Confirmed Bug description: We rely on network-manager dispatcher scripts on our desktop and laptop computers. The dispatcher scripts are used to update DNS records with nsupdate when the dhcp lease is renewed. With jammy this is not working anymore. It seems that dispatcher scripts are run only when the interface comes up (with action 'up') and with the initial dhcp lease (with action 'dhcp4-change'), but when the lease is renewed, the dispatcher scripts are not run with any action. The only action the dispatcher scripts are run regularly with is 'connectivity-change', which seems to occur twice in a row every few hours. I have made a simple script to log how the dispatcher scripts are run: /etc/NetworkManager/dispatcher.d/99-test: #!/bin/bash PATH='/bin:/sbin:/usr/bin:/usr/sbin' echo $(date) 0: $0 IFACE: $1 ACTION: $2 >> /tmp/nm.log This script proves that action 'dhcp4-change' only occurs when I manually restart NetworkManager.service or unplug and replug the ethernet cable. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1997553/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1882098] Re: Packagekit lets user install untrusted local packages in Bionic and Focal
Hello Seth, I can now confirm that it does not matter if the test users are in no groups. The issue persists. Lines 49 to 56 in the link I provided earlier describe the package- install-untrusted action which should be triggered when installing local packages: Install untrusted local file AFAIK this works as intended with other than aptcc backends, eg in Red Hat. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to packagekit in Ubuntu. https://bugs.launchpad.net/bugs/1882098 Title: Packagekit lets user install untrusted local packages in Bionic and Focal Status in packagekit package in Ubuntu: New Bug description: We have packagekit configured to allow users to install trusted packages from preconfigured repositories, but disallowed them to install any untrusted packages. The policykit configuration we use is following: [tld.univ.packagekit] Identity=unix-group:adm; Action=org.freedesktop.packagekit.package-install;org.freedesktop.packagekit.package-reinstall;org.freedesktop.packagekit.package-remove;org.freedesktop.packagekit.system-sources-refresh;org.freedesktop.packagekit.system-update;org.freedesktop.packagekit.repair-system; ResultAny=auth_self ResultActive=auth_self ResultInactive=auth_self [tld.univ.packagekit-deny] Identity=unix-user:*; Action=org.freedesktop.packagekit.package-install-untrusted; ResultAny=no We would expect this to prevent users from installing local packages downloaded from random repositories, however this does not seem to be the case. pkcon install-local random_package.deb will happily prompt for the user to authenticate and will install the package, while pkcon --allow-untrusted install-local random_package.deb will prompt for root password, which the user does not have. Our initial toughts was that the issue would be in packagekitd, but after further investigations it looks like the issue could be in aptcc backend. We are more than happy to provide you with further details, but the above should be enough to reproduce the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1882098/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1882098] Re: Packagekit lets user install untrusted local packages in Bionic and Focal
Hello Seth, the packagekit-deny rule should not be necessary, it's there to underline what is specifically not allowed. AFAIK, there are no other rules which could have granted this permission. This happens on a fresh install of Ubuntu where the above is the only modification to polkit rules. I'm on vacation since yesterday evening, so I cannot currently check if the groups have some kind of unexpected effect. See this for reference: https://github.com/hughsie/PackageKit/blob/master/policy/org.freedesktop.packagekit.policy.in The issue is that the command 'pkcon install-local evil-package-i-just- created.deb' triggers the action 'org.freedesktop.packagekit.package- install' instead of 'org.freedesktop.packagekit.package-install- untrusted' which it should. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to packagekit in Ubuntu. https://bugs.launchpad.net/bugs/1882098 Title: Packagekit lets user install untrusted local packages in Bionic and Focal Status in packagekit package in Ubuntu: New Bug description: We have packagekit configured to allow users to install trusted packages from preconfigured repositories, but disallowed them to install any untrusted packages. The policykit configuration we use is following: [tld.univ.packagekit] Identity=unix-group:adm; Action=org.freedesktop.packagekit.package-install;org.freedesktop.packagekit.package-reinstall;org.freedesktop.packagekit.package-remove;org.freedesktop.packagekit.system-sources-refresh;org.freedesktop.packagekit.system-update;org.freedesktop.packagekit.repair-system; ResultAny=auth_self ResultActive=auth_self ResultInactive=auth_self [tld.univ.packagekit-deny] Identity=unix-user:*; Action=org.freedesktop.packagekit.package-install-untrusted; ResultAny=no We would expect this to prevent users from installing local packages downloaded from random repositories, however this does not seem to be the case. pkcon install-local random_package.deb will happily prompt for the user to authenticate and will install the package, while pkcon --allow-untrusted install-local random_package.deb will prompt for root password, which the user does not have. Our initial toughts was that the issue would be in packagekitd, but after further investigations it looks like the issue could be in aptcc backend. We are more than happy to provide you with further details, but the above should be enough to reproduce the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1882098/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
