[Bug 2063998] Re: Cannot be found in the menu after installing! Ubuntu 24.04
ufw doesn't have a menu entry when installed as a snap or otherwise. Perhaps gufw or another application is installed? ** Project changed: ufw => ubuntu ** Changed in: ubuntu Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2063998 Title: Cannot be found in the menu after installing! Ubuntu 24.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/2063998/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2062456] Re: bug report in docker imagw download
This bug lacks detail and doesn't look specific to ufw. Closing. ** Information type changed from Private Security to Public ** Project changed: ufw => ubuntu ** Changed in: ubuntu Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2062456 Title: bug report in docker imagw download To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/2062456/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2062455] Re: bug report in docker imagw download
This bug lacks detail and doesn't look specific to ufw. Closing. ** Information type changed from Private Security to Public ** Project changed: ufw => ubuntu ** Changed in: ubuntu Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2062455 Title: bug report in docker imagw download To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/2062455/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2060535] Re: apparmor's is_container_with_internal_policy() does not recognize incus
Note that after this fix, snapd in containers needs to be at >= 2.62 for apparmor policy to load (snapd's snapd-apparmor needs the corresponding fix as this bug). This is currently in the candidate channel. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060535 Title: apparmor's is_container_with_internal_policy() does not recognize incus To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2060535/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2060535] Re: apparmor's is_container_with_internal_policy() does not recognize incus
This is already available in noble. An SRU for jammy and focal (and ideally bionic) would be nice. ** Changed in: apparmor (Ubuntu Bionic) Status: New => Triaged ** Changed in: apparmor (Ubuntu Focal) Status: New => Triaged ** Changed in: apparmor (Ubuntu Jammy) Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060535 Title: apparmor's is_container_with_internal_policy() does not recognize incus To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2060535/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2060535] Re: apparmor's is_container_with_internal_policy() does not recognize incus
https://gitlab.com/apparmor/apparmor/-/commit/659a187687fc8802045c113da0d12bc4b836d591 was committed upstream for this. It would be nice if this was SRU'd. ** Changed in: apparmor (Ubuntu Noble) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060535 Title: apparmor's is_container_with_internal_policy() does not recognize incus To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2060535/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2060535] [NEW] apparmor's is_container_with_internal_policy() does not recognize incus
Public bug reported:
apparmor is not loading for Ubuntu containers under incus. This is due
to `/lib/apparmor/rc.apparmor.functions` (18.04 uses
`/lib/apparmor/functions`):
is_container_with_internal_policy() {
# this function is sometimes called independently of
# is_apparmor_loaded(), so also define this here.
local ns_stacked_path="${SFS_MOUNTPOINT}/.ns_stacked"
local ns_name_path="${SFS_MOUNTPOINT}/.ns_name"
local ns_stacked
local ns_name
if ! [ -f "$ns_stacked_path" ] || ! [ -f "$ns_name_path" ]; then
return 1
fi
read -r ns_stacked < "$ns_stacked_path"
if [ "$ns_stacked" != "yes" ]; then
return 1
fi
# LXD and LXC set up AppArmor namespaces starting with "lxd-" and
# "lxc-", respectively. Return non-zero for all other namespace
# identifiers.
read -r ns_name < "$ns_name_path"
if [ "${ns_name#lxd-*}" = "$ns_name" ] && \
[ "${ns_name#lxc-*}" = "$ns_name" ]; then
return 1
fi
return 0
}
This can be fixed by adjusting it to have:
# LXD, LXC and incus set up AppArmor namespaces starting with "lxd-",
# "lxc-", and "incus-" respectively. Return non-zero for all other namespace
# identifiers.
read -r ns_name < "$ns_name_path"
if [ "${ns_name#lxd-*}" = "$ns_name" ] && \
[ "${ns_name#lxc-*}" = "$ns_name" ] && \
[ "${ns_name#incus-*}" = "$ns_name" ] ; then
return 1
fi
References:
* https://github.com/lxc/incus/issues/740
** Affects: apparmor (Ubuntu)
Importance: Undecided
Status: New
** Affects: apparmor (Ubuntu Bionic)
Importance: Undecided
Status: New
** Affects: apparmor (Ubuntu Focal)
Importance: Undecided
Status: New
** Affects: apparmor (Ubuntu Jammy)
Importance: Undecided
Status: New
** Affects: apparmor (Ubuntu Noble)
Importance: Undecided
Status: New
** Also affects: apparmor (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: apparmor (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: apparmor (Ubuntu Noble)
Importance: Undecided
Status: New
** Also affects: apparmor (Ubuntu Jammy)
Importance: Undecided
Status: New
** Description changed:
apparmor is not loading for Ubuntu containers under incus. This is due
to `/lib/apparmor/rc.apparmor.functions` (18.04 uses
`/lib/apparmor/functions`):
+ is_container_with_internal_policy() {
+ # this function is sometimes called independently of
+ # is_apparmor_loaded(), so also define this here.
+ local ns_stacked_path="${SFS_MOUNTPOINT}/.ns_stacked"
+ local ns_name_path="${SFS_MOUNTPOINT}/.ns_name"
+ local ns_stacked
+ local ns_name
- is_container_with_internal_policy() {
- # this function is sometimes called independently of
- # is_apparmor_loaded(), so also define this here.
- local ns_stacked_path="${SFS_MOUNTPOINT}/.ns_stacked"
- local ns_name_path="${SFS_MOUNTPOINT}/.ns_name"
- local ns_stacked
- local ns_name
+ if ! [ -f "$ns_stacked_path" ] || ! [ -f "$ns_name_path" ]; then
+ return 1
+ fi
- if ! [ -f "$ns_stacked_path" ] || ! [ -f "$ns_name_path" ]; then
- return 1
- fi
+ read -r ns_stacked < "$ns_stacked_path"
+ if [ "$ns_stacked" != "yes" ]; then
+ return 1
+ fi
- read -r ns_stacked < "$ns_stacked_path"
- if [ "$ns_stacked" != "yes" ]; then
- return 1
- fi
+ # LXD and LXC set up AppArmor namespaces starting with "lxd-" and
+ # "lxc-", respectively. Return non-zero for all other namespace
+ # identifiers.
+ read -r ns_name < "$ns_name_path"
+ if [ "${ns_name#lxd-*}" = "$ns_name" ] && \
+[ "${ns_name#lxc-*}" = "$ns_name" ]; then
+ return 1
+ fi
- # LXD and LXC set up AppArmor namespaces starting with "lxd-" and
- # "lxc-", respectively. Return non-zero for all other namespace
- # identifiers.
- read -r ns_name < "$ns_name_path"
- if [ "${ns_name#lxd-*}" = "$ns_name" ] && \
- [ "${ns_name#lxc-*}" = "$ns_name" ]; then
- return 1
- fi
-
- return 0
+ return 0
}
- ```
This can be fixed by adjusting it to have:
- ```
- # LXD, LXC and incus set up AppArmor namespaces starting with "lxd-",
- # "lxc-", and "incus-" respectively. Return non-zero for all other
namespace
- # identifiers.
- read -r ns_name < "$ns_name_path"
- if [ "${ns_name#lxd-*}" = "$ns_name" ] && \
- [ "${ns_name#lxc-*}" = "$ns_name" ] && \
- [ "${ns_name#incus-*}" = "$ns_name" ] ; then
- return 1
- fi
- return 0
+ # LXD, LXC and incus set up AppArmor namespaces starting with "lxd-",
+ # "lxc-", and "incus-" respectively. Return non-zero for all other
namespace
+ # identifiers.
+ read -r ns_name < "$ns_name_path"
+
[Bug 337763] Re: virt-manager reboot action is non-functional
** Changed in: virt-manager (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/337763 Title: virt-manager reboot action is non-functional To manage notifications about this bug go to: https://bugs.launchpad.net/virt-manager/+bug/337763/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1970731] Re: iptables empty when using firewalld
Reassigning to firewalld as the description mentions that ufw is disabled. This is not a bug though because iptables relies on certain tables/chains being used and it looks like firewalld doesn't use those (which is fine for firewalld to do). You should be able to see all netfilter firewall rules with 'nft' but you'll only see rules that are added to the (now non-default) tables/chains that iptables expects (INPUT, OUTPUT, etc). More specifically, 'nft' will see the rules that 'iptables' creates but not necessarily the other way around. ** Package changed: ufw (Ubuntu) => firewalld (Ubuntu) ** Changed in: firewalld (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1970731 Title: iptables empty when using firewalld To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firewalld/+bug/1970731/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1896772] Re: systemd-resolved configures no Current Scopes on start
** Changed in: isc-dhcp (Ubuntu) Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896772 Title: systemd-resolved configures no Current Scopes on start To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1896772/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1896772] Re: systemd-resolved configures no Current Scopes on start
** Changed in: ifupdown (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896772 Title: systemd-resolved configures no Current Scopes on start To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1896772/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1896772] Re: systemd-resolved configures no Current Scopes on start
** Also affects: ifupdown (Ubuntu) Importance: Undecided Status: New ** Also affects: isc-dhcp (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896772 Title: systemd-resolved configures no Current Scopes on start To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1896772/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1896772] Re: systemd-resolved configures no Current Scopes on start
I grep'd for 'netif' in /etc and noticed: $ sudo grep -r netif /etc /etc/network/if-down.d/resolved:statedir=/run/systemd/resolve/netif /etc/network/if-up.d/resolved:statedir=/run/systemd/resolve/netif /etc/dhcp/dhclient-exit-hooks.d/resolved:statedir=/run/systemd/resolve/netif /etc/network/if-up.d/resolved and /etc/dhcp/dhclient-exit- hooks.d/resolved have code like this: statedir=/run/systemd/resolve/netif mkdir -p $statedir but do not have a corresponding chown of /run/systemd/resolve/netif. There is a chown for `chown systemd-resolve:systemd-resolve "$statedir/$ifindex"` in /etc/network/if-up.d/resolved and /etc/dhcp/dhclient-exit-hooks.d/resolved. This system has been upgraded many, many times (at least since yakkety). dhclient is being used for this interface. ifupdown is installed. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896772 Title: systemd-resolved configures no Current Scopes on start To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896772/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1896772] Re: systemd-resolved configures no Current Scopes on start
I see this on 22.04 after upgrading from 20.04. $ journalctl |grep 'Failed to save link data' Apr 17 15:25:52 hostname systemd-resolved[19095]: Failed to save link data /run/systemd/resolve/netif/3: Permission denied Apr 17 15:25:52 hostname systemd-resolved[19095]: Failed to save link data /run/systemd/resolve/netif/3: Permission denied $ ls -ld /run/systemd/resolve/netif drwxr-xr-x 2 root root 40 Apr 17 14:46 /run/systemd/resolve/netif (note, I had tried to restart systemd-resolved) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896772 Title: systemd-resolved configures no Current Scopes on start To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896772/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1968608] Re: networking/firewall issues after upgrade when using iptables-nft
I filed https://github.com/docker-snap/docker-snap/issues/68 for the docker snap unconditionally using xtables. ** Bug watch added: github.com/docker-snap/docker-snap/issues #68 https://github.com/docker-snap/docker-snap/issues/68 ** Also affects: iptables (Ubuntu) Importance: Undecided Status: New ** Changed in: iptables (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1968608 Title: networking/firewall issues after upgrade when using iptables-nft To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1968608/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1968608] Re: networking/firewall issues after upgrade when using iptables-nft
** Description changed: Filing this issue in the hopes that it will help people who are upgrading from a system that previously used xtables to one that is using netfilter. ufw uses the 'iptables' suite of commands under the hood. As of iptables 1.8, iptables ships with two different backends for these commands: * nft (netfilter) * legacy (xtables) such that there are iptables-nft, iptables-legacy, ip6tables-nft, ip6tables-legacy, etc commands on the system. Distributions may choose to then install symlinks from these commands to the traditional command. Eg, iptables will point to either iptables-nft or iptables-legacy. These symlinks can be configured by the admin on Debian/Ubuntu-based systems with: $ sudo update-alternatives --config iptables # configures all the iptables* symlinks $ sudo update-alternatives --config ip6tables # configures all the ip6tables* symlinks ufw is fully compatible with either backend. iptables-nft and nftables (ie, the 'nft' command not part of 'iptables'; will refer to this here as 'nftables' for clarity) both work with the kernel netfilter and different software on the system may freely use iptables-nft or nftables (eg, ufw using iptables-nft with other software (eg, libvirt) using nftables is fine). Since iptables-nft works well for ufw's requirements, there hasn't been a compelling reason to migrate ufw to use 'nftables' instead of 'iptables'. While iptables-nft and nftables can be used together, you should NOT mix and match netfilter and xtables rules as the upstream kernel considers this undefined and the firewall may not work correctly. Before iptables 1.8, admins could not mix and match iptables and nftables (or software that used one or the other). With iptables 1.8, admins can choose to use iptables-legacy or nftables and/or iptables-nft. Older releases of distributions (eg, Ubuntu 20.04 LTS) defaulted to iptables-legacy as the iptables backend with the admin able to opt into iptables-nft. Newer releases of distributions (eg, Ubuntu 22.04 LTS) are choosing to default to iptables-nft instead. As mentioned, so long as all of the software on the system agrees on using either netfilter or xtables, everything should be fine. Use of the symlink mechanism (eg, the aforementioned 'update-alternatives' on Debian/Ubuntu) helps ensure everything works properly. Software that manipulates the firewall outside of the configured symlinks (or using iptables-legacy/iptables 1.6 while nftables is also in use) might introduce problems if they are not aware of the xtables/netfilter incompatibility. Eg, this might happen with snaps that ship their own iptables or nftables and unconditionally use it without considering existing rules on the system. The ufw snap will detect and use the correct backend for the system on startup. The lxd and multipass snaps will do the same. As such, eg, an Ubuntu 20.04 system that is configured with the default iptables-legacy backend can use the ufw deb from Ubuntu with the lxd and multipass snaps without issue (ufw follows the iptables symlink to use the legacy (xtables) backend to load firewall rules in early boot. When lxd and multipass are started, they see that legacy rules are in use and use xtables). Similarly, on an Ubuntu 22.04 system that is configured with the default iptables-nft backend, the ufw deb from Ubuntu will follow the iptables symlink to use the nft (netfilter) backend to load firewall rules in early boot. When lxd and multipass are started, the see that nft rules are in use and use netfilter. Users upgrading from earlier distributions that defaulted to the legacy backend to newer releases that use the nft backend may find that non- distro software isn't choosing the correct backend. You can see if this is the case by running: $ sudo iptables-nft -S and compare with: $ sudo iptables-legacy -S If one is populated and the other comes back with only: -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT then everything should be operating together ok. You should also check ip6tables-nft vs ip6tables-legacy and if you have 'nft' on your system, see that 'sudo nft list ruleset' has only accept rules if 'iptables- legacy -S' shows rules are in use. If there is a mixture of rules in both backends, you'll need to make everything use either netfilter or xtables. If things were working correctly before the upgrade, you might find that going back to iptables-legacy could make things work until you're ready to migrate to iptables-nft (on Debian/Ubuntu, see update-alternatives, above). The 'docker' snap as of 20.10.12 in the stable channel is known to unconditionally use xtables. At the time of this filing, it did not have a way to adjust to using netfilter, so if using the docker snap, you might have to update your system to use
[Bug 1968608] [NEW] networking/firewall issues after upgrade when using iptables-nft
Public bug reported: Filing this issue in the hopes that it will help people who are upgrading from a system that previously used xtables to one that is using netfilter. ufw uses the 'iptables' suite of commands under the hood. As of iptables 1.8, iptables ships with two different backends for these commands: * nft (netfilter) * legacy (xtables) such that there are iptables-nft, iptables-legacy, ip6tables-nft, ip6tables-legacy, etc commands on the system. Distributions may choose to then install symlinks from these commands to the traditional command. Eg, iptables will point to either iptables-nft or iptables-legacy. These symlinks can be configured by the admin on Debian/Ubuntu-based systems with: $ sudo update-alternatives --config iptables # configures all the iptables* symlinks $ sudo update-alternatives --config ip6tables # configures all the ip6tables* symlinks ufw is fully compatible with either backend. iptables-nft and nftables (ie, the 'nft' command not part of 'iptables'; will refer to this here as 'nftables' for clarity) both work with the kernel netfilter and different software on the system may freely use iptables-nft or nftables (eg, ufw using iptables-nft with other software (eg, libvirt) using nftables is fine). Since iptables-nft works well for ufw's requirements, there hasn't been a compelling reason to migrate ufw to use 'nftables' instead of 'iptables'. While iptables-nft and nftables can be used together, you should NOT mix and match netfilter and xtables rules as the upstream kernel considers this undefined and the firewall may not work correctly. Before iptables 1.8, admins could not mix and match iptables and nftables (or software that used one or the other). With iptables 1.8, admins can choose to use iptables-legacy or nftables and/or iptables-nft. Older releases of distributions (eg, Ubuntu 20.04 LTS) defaulted to iptables-legacy as the iptables backend with the admin able to opt into iptables-nft. Newer releases of distributions (eg, Ubuntu 22.04 LTS) are choosing to default to iptables-nft instead. As mentioned, so long as all of the software on the system agrees on using either netfilter or xtables, everything should be fine. Use of the symlink mechanism (eg, the aforementioned 'update-alternatives' on Debian/Ubuntu) helps ensure everything works properly. Software that manipulates the firewall outside of the configured symlinks (or using iptables-legacy/iptables 1.6 while nftables is also in use) might introduce problems if they are not aware of the xtables/netfilter incompatibility. Eg, this might happen with snaps that ship their own iptables or nftables and unconditionally use it without considering existing rules on the system. The ufw snap will detect and use the correct backend for the system on startup. The lxd and multipass snaps will do the same. As such, eg, an Ubuntu 20.04 system that is configured with the default iptables-legacy backend can use the ufw deb from Ubuntu with the lxd and multipass snaps without issue (ufw follows the iptables symlink to use the legacy (xtables) backend to load firewall rules in early boot. When lxd and multipass are started, they see that legacy rules are in use and use xtables). Similarly, on an Ubuntu 22.04 system that is configured with the default iptables-nft backend, the ufw deb from Ubuntu will follow the iptables symlink to use the nft (netfilter) backend to load firewall rules in early boot. When lxd and multipass are started, the see that nft rules are in use and use netfilter. Users upgrading from earlier distributions that defaulted to the legacy backend to newer releases that use the nft backend may find that non- distro software isn't choosing the correct backend. You can see if this is the case by running: $ sudo iptables-nft -S and compare with: $ sudo iptables-legacy -S If one is populated and the other comes back with only: -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT then everything should be operating together ok. You should also check ip6tables-nft vs ip6tables-legacy and if you have 'nft' on your system, see that 'sudo nft list ruleset' has only accept rules if 'iptables- legacy -S' shows rules are in use. If there is a mixture of rules in both backends, you'll need to make everything use either netfilter or xtables. If things were working correctly before the upgrade, you might find that going back to iptables-legacy could make things work until you're ready to migrate to iptables-nft (on Debian/Ubuntu, see update-alternatives, above). The 'docker' snap as of 20.10.12 in the stable channel is known to unconditionally use xtables. At the time of this filing, it did not have a way to adjust to using netfilter, so if using the docker snap, you might have to update your system to use iptables-legacy (on Debian/Ubuntu, see update-alternatives, above). Finally, if using various container/VM software with ufw on the host and everything agrees on using the same backend, you might check
[Bug 1968498] [NEW] Unhandled promise rejection after screenlock/unlock
Public bug reported: After upgrading from focal to jammy, I noticed this in my logs: Apr 10 14:05:40 host ubuntu-appindicat...@ubuntu.com[124051]: unable to update icon for software-update-available Apr 10 14:05:40 host gnome-shell[124051]: Unhandled promise rejection. To suppress this warning, add an error handler to your promise chain with .catch() or a try-catch block around your await expression. Stack trace of the failed promise: _checkNeededProperties@/usr/share/gnome-shell/extensions/ubuntu-appindicat...@ubuntu.com/appIndicator.js:133:33 _nameOwnerChanged@/usr/share/gnome-shell/extensions/ubuntu-appindicat...@ubuntu.com/appIndicator.js:154:18 _emit@resource:///org/gnome/gjs/modules/core/_signals.js:114:47 AppIndicatorsNameWatcher/this._watcherId<@/usr/share/gnome-shell/extensions/ubuntu-appindicat...@ubuntu.com/util.js:205:22 This happens after screenlock/unlock. It looks like https://github.com/ubuntu/gnome-shell-extension- appindicator/issues/334 was filed for this as well. ** Affects: gnome-shell-extension-appindicator (Ubuntu) Importance: Undecided Status: New ** Description changed: After upgrading from focal to jammy, I noticed this in my logs: - Apr 10 14:05:40 iolanthe ubuntu-appindicat...@ubuntu.com[124051]: unable to update icon for software-update-available - Apr 10 14:05:40 iolanthe gnome-shell[124051]: Unhandled promise rejection. To suppress this warning, add an error handler to your promise chain with .catch() or a try-catch block around your await expression. Stack trace of the failed promise: - _checkNeededProperties@/usr/share/gnome-shell/extensions/ubuntu-appindicat...@ubuntu.com/appIndicator.js:133:33 - _nameOwnerChanged@/usr/share/gnome-shell/extensions/ubuntu-appindicat...@ubuntu.com/appIndicator.js:154:18 - _emit@resource:///org/gnome/gjs/modules/core/_signals.js:114:47 - AppIndicatorsNameWatcher/this._watcherId<@/usr/share/gnome-shell/extensions/ubuntu-appindicat...@ubuntu.com/util.js:205:22 + Apr 10 14:05:40 host ubuntu-appindicat...@ubuntu.com[124051]: unable to update icon for software-update-available + Apr 10 14:05:40 host gnome-shell[124051]: Unhandled promise rejection. To suppress this warning, add an error handler to your promise chain with .catch() or a try-catch block around your await expression. Stack trace of the failed promise: + _checkNeededProperties@/usr/share/gnome-shell/extensions/ubuntu-appindicat...@ubuntu.com/appIndicator.js:133:33 + _nameOwnerChanged@/usr/share/gnome-shell/extensions/ubuntu-appindicat...@ubuntu.com/appIndicator.js:154:18 + _emit@resource:///org/gnome/gjs/modules/core/_signals.js:114:47 + AppIndicatorsNameWatcher/this._watcherId<@/usr/share/gnome-shell/extensions/ubuntu-appindicat...@ubuntu.com/util.js:205:22 This happens after screenlock/unlock. It looks like https://github.com/ubuntu/gnome-shell-extension- appindicator/issues/334 was filed for this as well. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1968498 Title: Unhandled promise rejection after screenlock/unlock To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-appindicator/+bug/1968498/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1967884] Re: several snap-confine denials for capability net_admin and perfmon on 22.04
The fsetid is actually quite old (at least 3 years; there may have been a Trello card for it). At one point it came in and I did analysis and tweaked the order of the priv dropping in snap-confine to get rid of it. Then some stuff was added to snap-confine and it came back. I always had it as a to-do to work through it, but weighing the necessity of keeping the priv-dropping solid vs getting rid of the noisy denial always kept it on the back-burner. Bottom line, the fsetid has to do with the delicate drop/raise/.../full drop dance we do and isn't new. I think you should keep that separate from these other two. The new ones feel like it's a delegation issue with the new kernel (ie where it depends on what is launching snap-confine/what snap-confine is launching), but maybe it is just as simple as the 5.15 kernel has new capabilities checks for things it didn't before. When looking at this, remember that the kernel rate limits capability denials differently than say, file rules and that it can be difficult to trigger the denials reliably without taking additional steps. John can help you with these techniques. I recall wanting to pull my hair out when investigating the fsetid denial until I nailed down how to get the logged denial reliably :) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1967884 Title: several snap-confine denials for capability net_admin and perfmon on 22.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1967884/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1967884] Re: several snap-confine denials for capability net_admin and perfmon on 22.04
** Summary changed: - several snap-confine denials for capability net_admin on 22.04 + several snap-confine denials for capability net_admin and perfmon on 22.04 ** Description changed: I recently upgraded to 22.04 and started seeing denials like: - Apr 5 08:57:39 localhost kernel: [ 31.386426] audit: type=1400 audit(1649167059.397:267): apparmor="DENIED" operation="capable" profile="/usr/lib/snapd/snap-confine" pid=2333 comm="snap-confine" capability=12 capname="net_admin" - Apr 5 08:58:14 localhost kernel: [ 66.234135] audit: type=1400 audit(1649167094.420:274): apparmor="DENIED" operation="capable" profile="/usr/lib/snapd/snap-confine" pid=5400 comm="snap-confine" capability=12 capname="net_admin" - Apr 5 08:59:50 localhost kernel: [ 162.033225] audit: type=1400 audit(1649167190.215:293): apparmor="DENIED" operation="capable" profile="/usr/lib/snapd/snap-confine" pid=7166 comm="snap-confine" capability=12 capname="net_admin" + Apr 05 09:38:51 iolanthe audit[5815]: AVC apparmor="DENIED" operation="capable" profile="/usr/lib/snapd/snap-confine" pid=5815 comm="snap-confine" capability=12 capname="net_admin" + Apr 05 09:38:51 iolanthe audit[5815]: AVC apparmor="DENIED" operation="capable" profile="/usr/lib/snapd/snap-confine" pid=5815 comm="snap-confine" capability=38 capname="perfmon" + Apr 05 09:38:51 iolanthe kernel: audit: type=1400 audit(1649169531.339:277): apparmor="DENIED" operation="capable" profile="/usr/lib/snapd/snap-confine" pid=5815 comm="snap-confine" capability=12 capname="net_admin" + Apr 05 09:38:51 iolanthe kernel: audit: type=1400 audit(1649169531.339:278): apparmor="DENIED" operation="capable" profile="/usr/lib/snapd/snap-confine" pid=5815 comm="snap-confine" capability=38 capname="perfmon" I've not been able to figure out what is causing this and will add more details if I do. Filing this in case other see it too. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1967884 Title: several snap-confine denials for capability net_admin and perfmon on 22.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1967884/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1967884] [NEW] several snap-confine denials for capability net_admin on 22.04
Public bug reported: I recently upgraded to 22.04 and started seeing denials like: Apr 5 08:57:39 localhost kernel: [ 31.386426] audit: type=1400 audit(1649167059.397:267): apparmor="DENIED" operation="capable" profile="/usr/lib/snapd/snap-confine" pid=2333 comm="snap-confine" capability=12 capname="net_admin" Apr 5 08:58:14 localhost kernel: [ 66.234135] audit: type=1400 audit(1649167094.420:274): apparmor="DENIED" operation="capable" profile="/usr/lib/snapd/snap-confine" pid=5400 comm="snap-confine" capability=12 capname="net_admin" Apr 5 08:59:50 localhost kernel: [ 162.033225] audit: type=1400 audit(1649167190.215:293): apparmor="DENIED" operation="capable" profile="/usr/lib/snapd/snap-confine" pid=7166 comm="snap-confine" capability=12 capname="net_admin" I've not been able to figure out what is causing this and will add more details if I do. Filing this in case other see it too. ** Affects: snapd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1967884 Title: several snap-confine denials for capability net_admin on 22.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1967884/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
** Tags removed: block-proposed block-proposed-jammy -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1950039/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
https://launchpad.net/ubuntu/+source/ufw/0.36.1-3ubuntu1 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1950039/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
** Changed in: ufw (Ubuntu) Status: New => Triaged ** Changed in: cloud-init (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1950039/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
Oh! I missed from the initial report that network-pre was deleted which clears up things considerably on my end (since I wasn't able to reproduce, I didn't see it locally either). :) Preparing an upload now. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1950039/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1956029] Re: ufw remains inactive at boot time
Thanks for the response and glad you got it worked out. It reminds me that I would like to document using fail2ban with ufw more. ** Changed in: ufw (Ubuntu) Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1956029 Title: ufw remains inactive at boot time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1956029/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
> This makes me want to understand the cloud-init configuration that is in play. Can you share it? I'm thinking I should upload: DefaultDependencies=no Before=network-pre.target Wants=network-pre.target local-fs.target After=local-fs.target Do you have any objections? This would remove the explicit sysinit from the dependency equation but I think it would otherwise achieve ufw's startup objectives. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1950039/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
> I don't believe your reproducer is valid - cloud-init is not installed anymore, as autopkgtest-buildvm-ubuntu-cloud removes it when building the VM, whereas it remains on the cloud images, as it's needed there to actually get the IP address during boot. Note, in https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/comments/9 I installed cloud-init and did some analysis also (but see below). > Though arguably I'd expect this to be fixed by removing DefaultDependencies again, if I looked at this correctly. Seems likely, though this change was done to fix an issue people were seeing on stack exchange for Debian/Ubuntu systems related to a race between encrypted filesystems and ufw. I guess I could add back DefaultDependencies=no and add After=local-fs.target, but I'm not sure what this would do in practice since local-fs.target is so close to the end of sysinit anyway (but see below). In 0.36.1-2, ufw has: DefaultDependencies=no Before=network.target In 0.36.1-3, ufw has (no DefaultDependencies=no): Before=network-pre.target Wants=network-pre.target cloud-init has (among other things): Before=sysinit.target Before=network-pre.target Wants=network-pre.target AIUI, with 0.36.1-2, ufw will tend to start right away due to DefaultDependencies=no and so will cloud-init so long as it finishes before sysinit. ufw need only finish before network.target, which is after network-pre.target. Eg, ufw and cloud-init race to complete but otherwise their dependencies directly don't affect each other. With 0.36.1-3, cloud-init starts early and before ufw since it must finish before sysinit.target and ufw cannot start until after sysinit.target is done. Because both must finish before network- pre.target, this pushes network-pre.target after sysinit (and of course, ufw), but other than that, there shouldn't be a problem since we have: 1. cloud-init starts / finishes 2. sysinit starts / finishes 3. ufw starts / finishes 4. network-pre reached 5. systemd-networkd starts / finishes 6. network reached IME, there is no obvious problem with the dependencies (as they relate to ufw) since cloud-init is allowed to start/finish before sysinit and network-pre just like before. It is just that now network-pre is guaranteed to be after sysinit (which from cloud-init's point of view, shouldn't necessarily be a concern). It is also guaranteed to be after ufw but, unless cloud-init is doing something with ufw such as perhaps enabling ufw and restarting the ufw service, cloud-init shouldn't care cause the ufw service doesn't do anything unless ufw is enabled (and even when it is enabled, it just loads firewall rules). This makes me want to understand the cloud-init configuration that is in play. Can you share it? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1950039/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1956029] Re: ufw remains inactive at boot time
Thanks for the bug report. A few things: 1. I'm not sure what 'networking stops' means precisely in the context of this bug report. Does 'ufw disable' restore the network? Is the network torn down? Something else (you are using a lot of limit rules instead of allow rules, I wonder if you are hitting limits...)? 2. 'journalctl -u ufw.service' isn't normally going to show you much since the command run from the service isn't very chatty. Better would be to look at /var/log/ufw.log around the time the networking stops. If /var/log/ufw.log doesn't exist on your distro, you should check /var/log/kern.log for firewall denials and then try to resolve them with new/modified firewall rules 3. It isn't clear if you used the check-requirements from https://git.launchpad.net/ufw/tree/tests/check-requirements or the one on the system. Which did you use? (Note, I just made a change to https://git.launchpad.net/ufw/tree/tests/check-requirements that you might want to use) 4. you didn't mention which distro you are using, but the ufw.service file is not what is shipped upstream (or Ubuntu or Debian). This is what has been shipped in Ubuntu and Debian for several years: [Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) DefaultDependencies=no Before=network.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target and this is what is upstream (Debian is the same except omits the 'Conflicts') and what should solve some issues (though I'm not sure it would solve your issues: [Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) Before=network-pre.target Wants=network-pre.target Conflicts=iptables.service ip6tables.service nftables.service firewalld.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target You may want to adjust the service file to be like the upstream one, then run 'sudo systemctl daemon-reload' and reboot. ** Changed in: ufw (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1956029 Title: ufw remains inactive at boot time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1956029/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1956029] Re: ufw remains inactive at boot time
> How to I ensure that ufw is fully up and initialised BEFORE the
fail2ban service starts?
This line from your existing fail2ban.service should be sufficient:
After=network.target iptables.service firewalld.service
ip6tables.service ipset.service nftables.service ufw.service
See https://www.freedesktop.org/software/systemd/man/systemd.unit.html
for details ("After= is the inverse of Before=, i.e. while Before=
ensures that the configured unit is started before the listed unit
begins starting up, After= ensures the opposite, that the listed unit is
fully started up before the configured unit is started.")
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1956029
Title:
ufw remains inactive at boot time
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1956029/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1956029] Re: ufw remains inactive at boot time
> 4. you didn't mention which distro you are using This would be good to know since some distros are using iptables 1.8.x which has two different backends that are in play. Which distro are you using and what is the output of `iptables --version` -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1956029 Title: ufw remains inactive at boot time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1956029/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
** Attachment added: "plot-2.svg" https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+attachment/5550320/+files/plot-2.svg -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
** Attachment added: "plot-3.svg" https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+attachment/5550321/+files/plot-3.svg -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
Attached are two 'systemd-analyze plot's for the autopktest jammy system with cloud-init and ufw installed. plot-2.svg is for booting the system with 0.36.1-2 (current jammy) and plot-3.svg is 0.36.1-3 (proposed jammy). Notice how plot-2.svg, ufw and systemd-networkd start quite a bit earlier than in plot-3.svg. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
@juliank - note I wasn't so much talking about 'blame' as much as understanding, so I apologize if it came across that way. Since I wasn't able to reproduce, I was trying to reason through my thoughts to help the discussion go further since I'm not able to diagnose it myself. In a nutshell, I have concerns that the ufw service has a side effect that somewhere else in the system is dependent on. That other part of the system should be setup to work without ufw in the mix. I'm also concerned that users might face issues if ufw is purged or if other similarly configured software is installed (eg, firewalld). With that in mind, it seems odd that a service that does nearly nothing by default would affect the system by having a Before/Wants on network- pre.target. It also seems odd that going from very little dependencies (DefaultDependencies=no) to have only those for 'basic system initialization' would be a problem since those are not related to networking, etc. Eg, in today's autopkgtest jammy instance that I created with `autopkgtest-buildvm-ubuntu-cloud -r jammy` and rebooting with the proposed -3 of ufw installed: $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu Jammy Jellyfish (development branch) Release:22.04 Codename: jammy $ cat /proc/version_signature Ubuntu 5.13.0-19.19-generic 5.13.14 $ systemctl list-dependencies ufw.service ufw.service ● ├─system.slice ● ├─network-pre.target ● └─sysinit.target ● ├─apparmor.service ● ├─dev-hugepages.mount ● ├─dev-mqueue.mount ● ├─keyboard-setup.service ● ├─kmod-static-nodes.service ● ├─multipathd.service ● ├─plymouth-read-write.service ○ ├─plymouth-start.service ● ├─proc-sys-fs-binfmt_misc.automount ● ├─setvtrgb.service ● ├─sys-fs-fuse-connections.mount ● ├─sys-kernel-config.mount ● ├─sys-kernel-debug.mount ● ├─sys-kernel-tracing.mount ● ├─systemd-ask-password-console.path ○ ├─systemd-binfmt.service ○ ├─systemd-boot-system-token.service ● ├─systemd-journal-flush.service ● ├─systemd-journald.service ○ ├─systemd-machine-id-commit.service ● ├─systemd-modules-load.service ○ ├─systemd-pstore.service ● ├─systemd-random-seed.service ● ├─systemd-sysctl.service ● ├─systemd-sysusers.service ● ├─systemd-timesyncd.service ● ├─systemd-tmpfiles-setup-dev.service ● ├─systemd-tmpfiles-setup.service ● ├─systemd-udev-trigger.service ● ├─systemd-udevd.service ● ├─systemd-update-utmp.service ● ├─cryptsetup.target ● ├─local-fs.target ● │ ├─-.mount ● │ ├─boot-efi.mount ○ │ ├─systemd-fsck-root.service ● │ └─systemd-remount-fs.service ● ├─swap.target ● └─veritysetup.target Seeing what depends on ufw, there is very little: $ systemctl list-dependencies ufw.service --reverse ufw.service ● └─multi-user.target ● └─graphical.target I can also say that nothing in this VM depends on network-pre other than ufw: $ systemctl list-dependencies --reverse network-pre.target network-pre.target ● └─ufw.service and that there is not much depending on network.target: $ systemctl list-dependencies --reverse network.target network.target ○ ├─netplan-ovs-cleanup.service ● └─systemd-networkd.service Rebooting with ufw -2 installed, all of the above is the same except ufw's dependencies are nearly nothing: $ systemctl list-dependencies ufw.service ufw.service ● └─system.slice This autopkgtest VM doesn't have cloud-init installed (which is consistent with why I'm not seeing it in here like I am not in Debian) and I don't know what cloud-init config to provide to provide any additional diagnosis. I can say that if I install cloud-init, it add a dependency on on network-pre.target (still with -2 of ufw): $ systemctl list-dependencies network-pre.target --reverse network-pre.target ○ └─cloud-init-local.service It has: $ cat /usr/lib/systemd/system/cloud-init-local.service [Unit] Description=Initial cloud-init job (pre-networking) DefaultDependencies=no Wants=network-pre.target After=hv_kvp_daemon.service After=systemd-remount-fs.service Before=NetworkManager.service Before=network-pre.target Before=shutdown.target Before=sysinit.target Conflicts=shutdown.target RequiresMountsFor=/var/lib/cloud [Service] Type=oneshot ExecStart=/usr/bin/cloud-init init --local ExecStart=/bin/touch /run/cloud-init/network-config-ready RemainAfterExit=yes TimeoutSec=0 # Output needs to appear in instance console output StandardOutput=journal+console [Install] WantedBy=cloud-init.target I notice that it has a `Before=sysinit.target` and DefaultDependencies=no. Is cloud-init in our infrastructure configured to run ufw? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+subscriptions -- ubuntu-bugs mailing
[Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
** Changed in: ufw (Ubuntu) Status: Triaged => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
@juliank - where did you see these errors? I booted with a freshly created autopkgtest jammy vm, installed the package from proposed and it worked fine. Please see my previous comments-- this does not seem to be a bug in ufw since it is using the documented unit setup that systemd recommends for firewall software (and that other firewall software use, such as firewalld) and this has been in Debian for some time now with no bug reports (indeed, it solved issues). Your initial report shows that lots of other units have the ordering cycle issue that you mentioned so I'm not sure why ufw would be singled out. So we're all on the same page, this was the change: -DefaultDependencies=no -Before=network.target +Before=network-pre.target +Wants=network-pre.target and I'll add this from debian/changelog: +- use Before and Wants on network-pre.target. Per systemd documentation, + "network-pre.target is a target that may be used to order services + before any network interface is configured. Its primary purpose is for + usage with firewall services". Because network-pre.target is a passive + unit, "services that want to be run before the network is configured + should place Before=network-pre.target and also set + Wants=network-pre.target to pull it in" +- remove DefaultDependencies=no so that we pull in default dependencies + for "basic system initialization". While ufw is meant to come up before + networking, there is no reason why it shouldn't come up after sysinit. + This should help make ufw startup more robust on systems that need + something from sysinit. The ufw unit itself does very little unless ufw is enabled since /lib/ufw/ufw-init exits very quickly when it is not enabled. As such, it seems to me that the ufw upload may have uncovered a latent issue in our early boot (but that wouldn't be a bug in ufw itself) where Ubuntu may not be supporting the documented behavior for network-pre.target. Finally, it has been a couple of months since this report; is it possible to rerun wherever this was run to see if it is still an issue (as mentioned, no bug reports in Debian and so perhaps things floated in that resolved this)? I would rerun autopkgtests, but they all have passed. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1726856] Re: ufw does not start automatically at boot
@Stefan, I suggest you try the fix that is in Debian. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990834#27 @Myron, yours sounds like a different issue. I suggest you file a new bug, downloading https://git.launchpad.net/ufw/tree/tests/check- requirements and including the output of 'sudo sh /path/to/check- requirements'. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1726856 Title: ufw does not start automatically at boot To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1726856/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1643706] Re: snap apps need to be able to browse outside of user $HOME dir. for Desktop installs
** Changed in: snapd (Ubuntu) Assignee: Jamie Strandboge (jdstrand) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1643706 Title: snap apps need to be able to browse outside of user $HOME dir. for Desktop installs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1643706/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1951018] Re: No ability to discern IPv4 vs IPv6 rules through Python
** Also affects: ufw Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1951018 Title: No ability to discern IPv4 vs IPv6 rules through Python To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1951018/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
Also, to be clear, when I say I can't look at the ufw portions 'for a while', I mean ~10 days (doing this from my phone). Thinking about this, my thinking is this is less about the Before/Wants on network-pre and the removal of DefaultDependencies and more about Before=network being removed (with perhaps nothing else doing that? ie, I don't think this an ufw bug; I think the change uncovered something). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
I mention firewalld cause while ufw could be reverted, firewalld users would presumably also hit it, as well as any other software that does it. If the ufw change is reverted, IME someone should audit the archive for other occurrences of this pattern and update the units accordingly). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
Fyi, the current configuration is the same as firewalld upstream and what is in Debian, Moreover it is following systemd documentation for firewall software so I wonder if the change simply uncovered a latent bug Fyi, I won't be able to look at this for a while so if you need to back it out, please do an ubuntu1 upload (though it would be great if someone more familiar with systemd-networkd thought through my latent bug comment). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1946804] Re: ufw breaks boot on network root filesystem
Tested 0.36-6ubuntu1 on focal. apt upgrade succeeded and after reboot the firewall came up with the expected rules in the expected order and I spot-checked allowed and deny traffic. I didn't test on an iSCSI system so won't add verification-done-focal at this time, but I think the testing is probably sufficient for that (I'll let others decide). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1946804 Title: ufw breaks boot on network root filesystem To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1946804/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1946804] Re: ufw breaks boot on network root filesystem
Tested 0.36-0ubuntu0.18.04.2 on bionic. apt upgrade succeeded and after reboot the firewall came up with the expected rules in the expected order and I spot-checked allowed and deny traffic. I didn't test on an iSCSI system so won't add verification-done-focal at this time, but I think the testing is probably sufficient for that (I'll let others decide). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1946804 Title: ufw breaks boot on network root filesystem To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1946804/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1933117] Re: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule
Tested 0.36-0ubuntu0.18.04.2 on bionic. apt upgrade succeeded and after reboot the firewall came up with the expected rules in the expected order and I spot-checked allowed and deny traffic. I was able to verify the this bug is fixed via the test steps. ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1933117 Title: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1933117/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1933117] Re: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule
Tested 0.36-6ubuntu1 on focal. apt upgrade succeeded and after reboot the firewall came up with the expected rules in the expected order. I was able to verify the this bug is fixed via the test steps. ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1933117 Title: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1933117/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1726856] Re: ufw does not start automatically at boot
I've looked at this issue again in reference to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990834 and while I still cannot reproduce, I plan to change to the following (I won't ship the commented out lines of course): [Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) #DefaultDependencies=no #Before=network.target Before=network-pre.target Wants=network-pre.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target This removes DefaultDependencies=no so that 'sysinit' will be pulled in and changes the single 'Before=network.target' to instead have Before=network-pre.target and Wants=network-pre.target. This won't help people who have different firewall software installed (like some of the comments), but should make startup more robust (eg, for those needing something from sysinit) while still allowing it to come up before the network. ** Bug watch added: Debian Bug tracker #990834 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990834 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1726856 Title: ufw does not start automatically at boot To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1726856/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1946804] Re: ufw breaks boot on network root filesystem
Ah, I hadn't checked that yet. Yes, please feel free to do the Impish SRU and the 0.36.1-2 that I just uploaded to Debian will float into 'J' after it opens. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1946804 Title: ufw breaks boot on network root filesystem To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1946804/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1946804] Re: ufw breaks boot on network root filesystem
For Impish, lets update debian/master, then I'll upload there and sync to Ubuntu. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1946804 Title: ufw breaks boot on network root filesystem To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1946804/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1946804] Re: ufw breaks boot on network root filesystem
I merged the changes into master. Thanks Mauricio! ** Changed in: ufw Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1946804 Title: ufw breaks boot on network root filesystem To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1946804/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1794064] Re: Clicking a hyperlink in a PDF fails to open it if the default browser is a snap
Olivier, yes, I shouldn't be assigned. Ian, you're right the profile is
suboptimal (it's also old so likely needs updating).
Do note that this is a separate named profile and evince (and if this is
put in an abstraction, anything that uses the abstraction) only has the
`/{,snap/core/[0-9]*/}usr/bin/snap mrCx -> snap_browser,` rule which
means that it is able to run the 'snap' command (needed since everything
in /snap/bin points to /usr/bin/snap) which at the time I wrote the
profile meant that access to this socket was needed as part of snap run.
IIRC, snapd should be protecting certain actions by uid connecting to it
(eg, you are root or not), but it has been a while since I've looked at
that. Evince is not a snap though so if snapd does any checks on 'is the
client a snap' then those would fail and evince would be able to do
whatever a non-root user could do with the 'snap' command via the
socket.
For snap run, we can see that the snap_browser profile limits what can
be used with 'run' since (at the time I wrote the comment) 'snap run'
required being able to look at the meta/snap.yaml of the specific snap.
This 'works' (worked?) but is brittle since if snap run changed to lift
this requirement (eg, 'snap run' just passed the name of the unresolved
symlink to snapd over the socket and let snapd start the snap, perhaps
via userd, etc) then this falls apart.
The profile was put up as an example as what could be done at the time without
any help from snapd. I never particularly cared for it cause it was brittle and
not designed. I'm not sure how to fix this, but here are some thoughts:
* evince is just executing stuff from /snap/bin (probably via the system's
xdg-open). Assuming xdg-open, the system's xdg-open (or whatever evince is
using to decide and launch the default browser) could itself be fixed in Ubuntu
to launch a different command that behaved better. This wouldn't necessarily
fix other distros (though this is the evince profile in Debian and Ubuntu, so
*technically*, if you got this change (to presumably xdg-open) into them, you
could update the evince profile in them accordingly)
* In lieu of that, if the profile still worked as intended, snapd could be
hardened to look to check more than if the connecting process is root or a
snap; it could also see if it is running under a non-snap profile, then limit
access to the socket API accordingly. This has drawbacks and could break people
who have written custom profiles similar to what I presented.
* I suppose an alternative approach would be to have symlinks in /snap/bin for
things that are registered as browsers (or just the default browser) point to a
designed snap command. Eg:
/snap/bin/firefox -> /usr/bin/snap # keep the
existing one too
/snap/bin/default-browser-is-a-snap -> /usr/bin/snap-browser # name is
illustrative, TBD
Now firefox, chromium, opera, brave, etc snaps registers themselves as
being capable of being a default browser with snapd, then snapd
registers with the system that /snap/bin/default-browser-is-a-snap is
the default browser (so system utilities like xdg-open don't need to
change) and /usr/bin/snap-browser is written to be safe (eg, only able
to 'snap run' the configured default browser, nothing else) and apparmor
profiles are adjusted to have `/{,snap/core/[0-9]*/}usr/bin/snap-browser
Uxr,` (or similar). The /snap/bin/default-browser-is-a-snap path is
illustrative and there isn't really a need for it at all. Could simply
perhaps have snapd register /usr/bin/snap-browser as the default browser
on the system (it now needs to know what snapd configured as the default
browser snap though) and forego the symlink.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1794064
Title:
Clicking a hyperlink in a PDF fails to open it if the default browser
is a snap
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1794064/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1794064] Re: Clicking a hyperlink in a PDF fails to open it if the default browser is a snap
** Changed in: evince (Ubuntu) Assignee: Jamie Strandboge (jdstrand) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1794064 Title: Clicking a hyperlink in a PDF fails to open it if the default browser is a snap To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1794064/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1933117] Re: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule
** Also affects: ufw (Ubuntu) Importance: Undecided Status: New ** Changed in: ufw (Ubuntu) Status: New => In Progress ** Changed in: ufw (Ubuntu) Assignee: (unassigned) => Jamie Strandboge (jdstrand) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1933117 Title: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1933117/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1726856] Re: ufw does not start automatically at boot
@cajicas215 - your comment is not helpful. If you look at the other comments in this bug, there has been nothing to fix in ufw. I suggest looking at the comments in this bug and seeing if any of the issues others have seen apply to you. If not, please report a new bug with steps to reproduce. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1726856 Title: ufw does not start automatically at boot To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1726856/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1726856] Re: ufw does not start automatically at boot
@Fabian - your change both makes the firewall start after networking,
brings python into the boot process (which can slow down boot) and
changes the intent of 'systemctl stop ufw' from unloading the firewall
to disabling the firewall in the moment and forever in the future, which
is inappropriate ('systemctl stop' is supposed to stop the service until
someone runs 'systemctl start' again or reboot. 'systemctl disable' is
meant to prevent the service from starting on reboot. This might be fine
for your system, but it would not be appropriate as a default in ufw or
distributions. Also, this bug is in upstream ufw and you are reporting
an issue on Raspbian, who would supply the packaging for ufw. If you
still feel the change should be made, I suggest filing a bug with
Raspbian so they can change their packaging of ufw.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1726856
Title:
ufw does not start automatically at boot
To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/1726856/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1921350] Re: UFW hangs indefinitely on any action
There is another bug related to ansible in https://bugs.launchpad.net/ufw/+bug/1911637. I suggest following that one. Leaving this one as Expired. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1921350 Title: UFW hangs indefinitely on any action To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1921350/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1934931] Re: (X)ubuntu 20.04: GUFW and MS-Teams slow down traffic intermittently
It is unclear from the description that this has anything to do with networking. Are there any firewall denials in the logs (eg, /var/log/ufw.log or /var/log/kern.log)? If you disable ufw (sudo ufw disable) does the problem go away? As an aside, IIRC, MS-Teams is not a lightweight application and I suspect this could be memory consumption unrelated to the firewall. ** Changed in: ufw (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1934931 Title: (X)ubuntu 20.04: GUFW and MS-Teams slow down traffic intermittently To manage notifications about this bug go to: https://bugs.launchpad.net/gui-ufw/+bug/1934931/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1909373] Re: package ufw 0.36-0ubuntu0.18.04.1 failed to install/upgrade: installed ufw package post-installation script subprocess returned error exit status 10
There isn't anything in the logs the indicates that there what happened. Do you have any other information? ** Changed in: ufw (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1909373 Title: package ufw 0.36-0ubuntu0.18.04.1 failed to install/upgrade: installed ufw package post-installation script subprocess returned error exit status 10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1909373/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1898696] Re: add some deliminiter between ipv4 and ipv6 in ufw status
Thanks you for the report. It is difficult to convey ipv4 vs ipv6 vs both in list form and currently ufw lists any ipv6 rules with '(v6)' as part of the To and From (as seen in your paste). It isn't clear to me how adding an 'IPv6' break would improve this... I'm going to mark this as wishlist while I think about it. Regarding the side note, the person who posted the question was unaware of https://bugs.launchpad.net/ufw/+bug/1880453 which speaks to future support (it isn't needed as ufw will use the nft backend if the system is configured to do so). ** Changed in: ufw (Ubuntu) Importance: Undecided => Wishlist ** Changed in: ufw (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1898696 Title: add some deliminiter between ipv4 and ipv6 in ufw status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1898696/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1911637] Re: Another app is currently holding the xtables lock
** Changed in: ufw Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1911637 Title: Another app is currently holding the xtables lock To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1911637/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1911637] Re: Another app is currently holding the xtables lock
Actually, in thinking about this, ufw could use 'iptables -w' under the hood. I recall having troubles with this approach when providing the fix for https://bugs.launchpad.net/ufw/+bug/1204579. I suggest following my advice in my last comment to avoid the issue while using 'iptables -w' is explored. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1911637 Title: Another app is currently holding the xtables lock To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1911637/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1911637] Re: Another app is currently holding the xtables lock
Thanks for the report. I read the ansible bug but this issue is actually coming from the underlying iptables tool. Something on the system is manipulating the firewall via iptables at the same time that the ufw command is being run. As described, this would happen with any firewall software. If only ufw is being used with ansible, perhaps ensure that the ufw commands are not being run in parallel. The upstream bug referenced docker, which will also manipulate the firewall with iptables; perhaps ensure that ufw configuration is applied before docker is started. I'm going to mark this bug as Invalid for now. Feel free to provide more information if you feel this is specific to ufw. ** Changed in: ufw (Ubuntu) Status: Confirmed => Invalid ** Changed in: ufw (Ubuntu) Status: Invalid => New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1911637 Title: Another app is currently holding the xtables lock To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1911637/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1889137] Re: HWE kernel is missing firmwares
I started seeing the issues that Sergio mentioned lately as well. I think this was caused by the recent automatic move from 5.8 to 5.11. I had the oem kernel installed (20.04 install) but then apt recently moved me to the hwe-5.8 kernel. More recently apt pulled in hwe-5.11 and I believe that is when I started seeing this issue. I didn't look at this super carefully, but it appears that some packaging for the lenovo oem-sutton.newell-ace-meta ppa transitioned me to linux-image-generic-hwe-20.04 (fine) which at the time was 5.8 (on Jul 22 linux-generic-hwe-20.04:amd64 5.8.0.63.71~20.04.45 got installed, according to /var/log/dpkg.log.1). I rebooted into this kernel and was happy. Sometime in July, 5.11.0.22.23~20.04.6 came into -security and -updates, but I didn't install it. Later I performed an apt-get dist-upgrade and was upgraded to 5.11.0.25.27~20.04.10 on Aug 6. Today I upgraded again to 5.11.0-27.29~20.04.1. As it happens, I did not boot into either of the 5.11 kernels and am still on 5.8 (5.8.0-63.71~20.04.1-generic). I reinstalled linux-firmware just now and it readily demonstrates the issue: $ sudo dpkg -i ./linux-firmware_1.187.16_all.deb (Reading database ... 260812 files and directories currently installed.) Preparing to unpack .../linux-firmware_1.187.16_all.deb ... Unpacking linux-firmware (1.187.16) over (1.187.16) ... Setting up linux-firmware (1.187.16) ... update-initramfs: Generating /boot/initrd.img-5.11.0-27-generic W: Possible missing firmware /lib/firmware/i915/skl_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/bxt_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/kbl_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/glk_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/kbl_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/kbl_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/cml_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/icl_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/ehl_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/ehl_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/tgl_huc_7.5.0.bin for module i915 W: Possible missing firmware /lib/firmware/i915/tgl_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/tgl_huc_7.5.0.bin for module i915 W: Possible missing firmware /lib/firmware/i915/tgl_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/dg1_dmc_ver2_02.bin for module i915 update-initramfs: Generating /boot/initrd.img-5.11.0-25-generic W: Possible missing firmware /lib/firmware/i915/skl_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/bxt_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/kbl_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/glk_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/kbl_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/kbl_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/cml_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/icl_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/ehl_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/ehl_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/tgl_huc_7.5.0.bin for module i915 W: Possible missing firmware /lib/firmware/i915/tgl_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/tgl_huc_7.5.0.bin for module i915 W: Possible missing firmware /lib/firmware/i915/tgl_guc_49.0.1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/dg1_dmc_ver2_02.bin for module i915 update-initramfs: Generating /boot/initrd.img-5.8.0-63-generic $ From the above, we can see that the 5.8 kernel had no errors, but both the 5.11 ones do. As I have the i915 chipset on this device, I haven't rebooted yet as I need a functional system. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1889137 Title: HWE kernel is missing firmwares To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1889137/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1938005] Re: ufw ignores rules
Recall that ufw uses connection tracking so if you add a deny rule, you may need to expire the connection tracking. One way to do this is to run: `conntrack -D -d ` (see man conntrack for details). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1938005 Title: ufw ignores rules To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1938005/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1939305] [NEW] e2scrub shouldn't run in a container
Public bug reported: This bug is similar to https://bugs.launchpad.net/ubuntu/+source/util- linux/+bug/1589289 (fstrim), but for the e2fsprogs timer e2scrub_all.timer. IME, the container itself shouldn't be running 'ext4 Metadata Checks for All Filesystems...' and that should be left up to the host to handle. I noticed this in a 20.04 container. I suspect the fix is similar to fstrim and to simply add 'ConditionVirtualization=!container' to the systemd timer. ** Affects: e2fsprogs (Ubuntu) Importance: Undecided Status: New ** Description changed: This bug is similar to https://bugs.launchpad.net/ubuntu/+source/util- - linux/+bug/1589289 (fstrim), but for the e2fsprogs timers: - e2scrub@.service and e2scrub_all.timer. IME, the container itself - shouldn't be running 'ext4 Metadata Checks for All Filesystems...' and - that should be left up to the host to handle. I noticed this in a 20.04 - container. + linux/+bug/1589289 (fstrim), but for the e2fsprogs timer + e2scrub_all.timer. IME, the container itself shouldn't be running 'ext4 + Metadata Checks for All Filesystems...' and that should be left up to + the host to handle. I noticed this in a 20.04 container. I suspect the fix is similar to fstrim and to simply add - 'ConditionVirtualization=!container' to the systemd timers. + 'ConditionVirtualization=!container' to the systemd timer. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1939305 Title: e2scrub shouldn't run in a container To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1939305/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1938005] Re: ufw ignores rules
/etc/default/ufw has: DEFAULT_OUTPUT_POLICY="ACCEPT" This means that all outgoing traffic is allowed. If you would like to change that, you can use: $ sudo ufw deny outgoing This will make it more difficult for you to manage the firewall since you'll have to add rules like: $ sudo ufw allow out to any port 53 and the like. Note, using 'ufw reload' may not work as expected if you are running iptables commands by hand underneath it. In those case, I suggest: $ sudo /lib/ufw/ufw-init flush-all $ sudo ufw disable $ sudo ufw enable Please report back. Thanks again for the report. ** Changed in: ufw (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1938005 Title: ufw ignores rules To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1938005/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1938005] Re: ufw ignores rules
Thank you for the bug report. You mentioned that the problem happens after running `iptables -F`. This command removes all the rules from the firewall (see man iptables) so it would be expected that the firewall would not work correctly after running this. I'm going to mark this as Invalid, but if you have more information, feel free to add it. ** Changed in: ufw (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1938005 Title: ufw ignores rules To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1938005/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849753] Re: AppArmor profile prohibits classic snap from inheriting file descriptors
FYI, if people need to workaround this to get real work done, you can
add something like this to your bashrc:
snap_workaround() {
fn="/var/lib/snapd/apparmor/snap-confine/lp1849753"
test -e "$fn" && return
tmpfn=$(mktemp)
cat > "$tmpfn"
[Bug 1921350] Re: UFW hangs indefinitely on any action
Thanks you for reporting a bug. Are there other ufw commands running at the same time? Eg, what is the output of: $ ps auxww|grep ufw ** Changed in: ufw (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1921350 Title: UFW hangs indefinitely on any action To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1921350/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1914816] Re: ufw not logging if it decides to stop all traffic ? Confused
Thanks for the additional information! :) ** Changed in: ufw (Ubuntu) Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1914816 Title: ufw not logging if it decides to stop all traffic ? Confused To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1914816/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1914816] Re: ufw not logging if it decides to stop all traffic ? Confused
The check is not free, but it is an interesting idea to do this. I've created a wishlist bug for it: https://bugs.launchpad.net/ufw/+bug/1917325 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1914816 Title: ufw not logging if it decides to stop all traffic ? Confused To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1914816/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 881137] Re: UFW does not clean iptables setting from /etc/ufw/before.rules
CzBiX, ufw does not yet manage the nat table (though there have been a couple of false starts). However, it does manage the FORWARD chain with 'ufw route' so it is possible for you to create a chain in the nat table in /etc/ufw/before.rules, and then use ufw route for other things. This is described in 'man ufw-framework' in the EXAMPLES section. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/881137 Title: UFW does not clean iptables setting from /etc/ufw/before.rules To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/881137/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1914816] Re: ufw not logging if it decides to stop all traffic ? Confused
Hi. A few things: ufw is capable of logging (see 'man ufw' the part about 'ufw logging' as well as per rule logging with 'ufw ... log' or 'ufw ... log-all'. It is also capable of ipv6 (see /etc/default/ufw. Also, gufw is a different project than ufw, but it sounds like the issue you saw may be seeing is another firewall is in place. What is the output of 'sudo /usr/share/ufw/check-requirements'? ** Changed in: ufw (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1914816 Title: ufw not logging if it decides to stop all traffic ? Confused To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1914816/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1902915] Re: snapd doesn't ensure portals are available even when they are needed
snapd could help with Pawel's idea a bit. A snap could say "I need this and that to function" where "this" and "that" are a list of things snapd knows how to check their availability. snapd could then provide a warning to the user if any of those things aren't there (or expose that information to the snap in some manner). That seems plausible for something like portals, but possibly for other things like DBus services. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902915 Title: snapd doesn't ensure portals are available even when they are needed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1902915/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1897369] Re: apparmor: Allow cups-browsed to change nice value (CAP_SYS_NICE)
Till, it allows quite a few things (from man capabilities): CAP_SYS_NICE * Raise process nice value (nice(2), setpriority(2)) and change the nice value for arbitrary processes; * set real-time scheduling policies for calling process, and set scheduling policies and priorities for arbitrary processes (sched_setscheduler(2), sched_setparam(2), sched_setattr(2)); * set CPU affinity for arbitrary processes (sched_setaffinity(2)); * set I/O scheduling class and priority for arbitrary processes (io‐ prio_set(2)); * apply migrate_pages(2) to arbitrary processes and allow processes to be migrated to arbitrary nodes; * apply move_pages(2) to arbitrary processes; * use the MPOL_MF_MOVE_ALL flag with mbind(2) and move_pages(2). cups-browsed is probably just trying to renice itself, which isn't terrible for it to try, but it probably fails gracefully with this just being noise. If it does fail gracefully, you could consider an explicit deny rule to silence the log. Eg: deny capability sys_nice, That said, we've normally allowed system policy (ie, those shipped in debs) to use sys_nice if they have a legitimate use case for it. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1897369 Title: apparmor: Allow cups-browsed to change nice value (CAP_SYS_NICE) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1897369/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1904192] Re: ebtables can not rename just created chain
FYI, sponsored Alex's upload to hirsute-proposed where it is building. Did the same for groovy-proposed and it is sitting in unapproved waiting for the next steps of the SRU process. ** Changed in: iptables (Ubuntu) Status: Confirmed => Fix Committed ** Changed in: iptables (Ubuntu) Assignee: (unassigned) => Alex Murray (alexmurray) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1904192 Title: ebtables can not rename just created chain To manage notifications about this bug go to: https://bugs.launchpad.net/iptables/+bug/1904192/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1898280] Re: Please unrevert the apparmor audit rule filtering feature
Thanks John! :) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1898280 Title: Please unrevert the apparmor audit rule filtering feature To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1898280/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1903745] Re: upgrade from 1.1.14-2ubuntu1.8 to 1.1.14-2ubuntu1.9 breaks clusters
Can someone confirm that the affected systems are running systemd- networkd? That would more strongly suggest that https://bugs.launchpad.net/netplan/+bug/1815101 is related. Based on the description and the other bug, the security update doesn't seem to have regressed pacemaker; instead, it's a preexisting pacemaker/systemd interaction that causes this problem under certain circumstances for any pacemaker update. If you believe this assessment is in error, please provide more details. I'm concerned that without resolving the systemd issue, anything we do with the pacemaker packaging in an SRU/follow-up update would simply reintroduce the condition that prompted filing this bug. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1903745 Title: upgrade from 1.1.14-2ubuntu1.8 to 1.1.14-2ubuntu1.9 breaks clusters To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1903745/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1898547] Re: neutron-linuxbridge-agent fails to start with iptables 1.8.5
FYI, 1.8.5-3ubuntu3 was uploaded to hirsute-proposed yesterday. 1.8.5-3ubuntu2.20.10.1 is in the unapproved queue for groovy-proposed. Alex said he'd do the SRU paperwork. ** Changed in: iptables (Ubuntu Hirsute) Status: Triaged => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1898547 Title: neutron-linuxbridge-agent fails to start with iptables 1.8.5 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1898547/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1899218] Re: Incorrect warning from apparmor_parser on force complained profiles
FYI, this is part of the groovy upload in unapproved. ** Changed in: apparmor (Ubuntu) Status: New => Fix Committed ** Changed in: apparmor (Ubuntu) Assignee: (unassigned) => John Johansen (jjohansen) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1899218 Title: Incorrect warning from apparmor_parser on force complained profiles To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1899218/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1899046] Re: /usr/bin/aa-notify:ModuleNotFoundError:/usr/bin/aa-notify@39
This has been uploaded to groovy and is currently in unapproved. ** Changed in: apparmor (Ubuntu) Status: In Progress => Fix Committed ** Changed in: apparmor (Ubuntu) Assignee: (unassigned) => Emilia Torino (emitorino) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1899046 Title: /usr/bin/aa-notify:ModuleNotFoundError:/usr/bin/aa-notify@39 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1899046/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1898280] Re: Please unrevert the apparmor audit rule filtering feature
FYI, John refreshed the patchset to v20 and reenabled audit rule filtering and submitted to https://lists.ubuntu.com/archives/kernel- team/2020-October/113932.html. Since this is a significant change, it will be considered for a stable release update (SRU) after groovy release (to allow for peer review, QA, etc). ** Changed in: linux (Ubuntu) Status: Triaged => In Progress ** Changed in: linux (Ubuntu) Milestone: None => groovy-updates -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1898280 Title: Please unrevert the apparmor audit rule filtering feature To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1898280/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1726856] Re: ufw does not start automatically at boot
@Muhammad - can you run: $ sudo /usr/share/ufw/check-requirements and paste the results? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1726856 Title: ufw does not start automatically at boot To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1726856/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1898280] Re: Please unrevert the apparmor audit rule filtering feature
After more discussion with John, while groovy does have a newer stacking patchset, it doesn't have the latest patchset that resolves the audit subsystem. Unfortunately, as of today, all of those patches haven't been signed-off on yet so there might be future changes. ** Description changed: Ubuntu carried a patch to apparmor for audit rule filtering, but it was reverted due to conflicts related to secids with earlier LSM stacking patchsets. The upstream LSM stacking patchset is believed to resolve - these issues and groovy now carries the updated LSM stacking patchset. + these issues and groovy now carries the updated LSM stacking patchset + (CORRECTION: groovy's stacking patchset was revved but doesn't have the + latest so we'd need to refresh the full stack to reenable the feature). As such, please re-enable the audit rule filtering feature in apparmor. While this could be an SRU, having it in groovy release would be ideal. ** Description changed: Ubuntu carried a patch to apparmor for audit rule filtering, but it was reverted due to conflicts related to secids with earlier LSM stacking patchsets. The upstream LSM stacking patchset is believed to resolve - these issues and groovy now carries the updated LSM stacking patchset - (CORRECTION: groovy's stacking patchset was revved but doesn't have the - latest so we'd need to refresh the full stack to reenable the feature). - As such, please re-enable the audit rule filtering feature in apparmor. + these issues and groovy now carries the updated LSM stacking patchset.As + such, please re-enable the audit rule filtering feature in apparmor. - While this could be an SRU, having it in groovy release would be ideal. + CORRECTION: groovy's stacking patchset was revved but doesn't have the + latest so we'd need to refresh the full stack to reenable the audit rule + filtering feature. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1898280 Title: Please unrevert the apparmor audit rule filtering feature To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1898280/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1898280] [NEW] Please unrevert the apparmor audit rule filtering feature
Public bug reported: Ubuntu carried a patch to apparmor for audit rule filtering, but it was reverted due to conflicts related to secids with earlier LSM stacking patchsets. The upstream LSM stacking patchset is believed to resolve these issues and groovy now carries the updated LSM stacking patchset. As such, please re-enable the audit rule filtering feature in apparmor. While this could be an SRU, having it in groovy release would be ideal. ** Affects: linux (Ubuntu) Importance: High Assignee: John Johansen (jjohansen) Status: Triaged ** Changed in: linux (Ubuntu) Importance: Undecided => High ** Changed in: linux (Ubuntu) Status: New => Triaged ** Changed in: linux (Ubuntu) Assignee: (unassigned) => John Johansen (jjohansen) ** Description changed: Ubuntu carried a patch to apparmor for audit rule filtering, but it was reverted due to conflicts related to secids with earlier LSM stacking patchsets. The upstream LSM stacking patchset resolved these issues and groovy now carries the updated LSM stacking patchset. As such, please re-enable the audit rule filtering feature in apparmor. + + While this could be an SRU, having it in groovy release would be ideal. ** Description changed: Ubuntu carried a patch to apparmor for audit rule filtering, but it was reverted due to conflicts related to secids with earlier LSM stacking - patchsets. The upstream LSM stacking patchset resolved these issues and - groovy now carries the updated LSM stacking patchset. As such, please - re-enable the audit rule filtering feature in apparmor. + patchsets. The upstream LSM stacking patchset is believed to resolve + these issues and groovy now carries the updated LSM stacking patchset. + As such, please re-enable the audit rule filtering feature in apparmor. While this could be an SRU, having it in groovy release would be ideal. ** Summary changed: - Please unrevert the audit rule filtering feature + Please unrevert the apparmor audit rule filtering feature -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1898280 Title: Please unrevert the apparmor audit rule filtering feature To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1898280/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1898038] Re: docker-support/multipass-support broken with system apparmor3 (20.10)
"We could use snap-update-ns to hide the host's /etc if those specific interfaces are connected. We could then present the relevant file from the base snap." I think hiding all of /etc would be regression prone for existing snaps. We could start to do this in the future if a snap specifies 'base: core22' though. However, expressing what to do with /etc/apparmor and /etc/apparmor.d via the interface code has a few advantages: 1. only multipass-support and docker-support are affected and bind mounts for /etc/apparmor* would be targeted only to these 2. the interface code knows about bases and can specify the etc/apparmor* from the appropriate base 3. snap-confine doesn't need to be adjusted (since snap-update-ns would be handling the mounts) '2' could be simplified by vendoring /etc/apparmor and /etc/apparmor.d into snapd at a predictable location (eg, in usr/lib/snapd/aa2/etc/apparmor and usr/lib/snapd/aa2/etc/apparmor.d (or somewhere)) such that you don't have to search around for the base in use. This would be more predictable and require less coordination for the fix. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1898038 Title: docker-support/multipass-support broken with system apparmor3 (20.10) To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1898038/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1898038] Re: docker-support/multipass-support broken with system apparmor3 (20.10)
** Description changed:
The docker-support and multipass-support interfaces allow access to
/sbin/apparmor_parser.
/sbin/apparmor_parser is supplied by the core, core18 and core20 base
snaps.
/etc/apparmor* comes from the host, which on groovy has apparmor3.
Snaps using docker-support and multipass-support are completely broken
on groovy when using core and core18. On core20, policy loads with
warnings.
Transparent solution is to ship the /etc/apparmor and /etc/apparmor.d in
- the base snaps, and bind mount these into place (eg, via snap-confine).
+ the base snaps, and bind mount these into place (eg, via snap-confine or
+ snap-update-ns).
- Snaps can fix themselves with layouts.
+ Snaps can workaround this themselves with layouts (while we should not
+ force this on publishers, this could be done to unbreak a snap before
+ the fix is in place).
Note, there are plans to vendor apparmor3 into snapd for cross-distro
support and that will happen in the 21.04 cycle. However, that doesn't
fix snaps that plugs docker-support and multipass-support and load their
own policy.
# core
$ cat /tmp/core.profile
#include
profile test-core-profile {
#include
}
$ sudo /snap/core/current/sbin/apparmor_parser -r /tmp/core.profile
/snap/core/current/sbin/apparmor_parser: unknown option (policy-features) in
config file.
AppArmor parser error for /tmp/core.profile in /etc/apparmor.d/tunables/etc
at line 25: Could not open 'if'
[1]
$ sudo aa-status | grep test-core
[1]
# core18
$ cat /tmp/core18.profile
#include
profile test-core18-parser {
#include
}
$ sudo /snap/core18/current/sbin/apparmor_parser -r /tmp/core18.profile
/snap/core18/current/sbin/apparmor_parser: unknown option (policy-features)
in config file.
AppArmor parser error for /tmp/core18.profile in /etc/apparmor.d/tunables/etc
at line 25: Could not open 'if'
[1]
$ sudo aa-status | grep test-core18
[1]
# core20
$ cat /tmp/core20.profile
#include
profile test-core20-parser {
#include
}
$ sudo /snap/core20/current/sbin/apparmor_parser -r /tmp/core20.profile
/snap/core20/current/sbin/apparmor_parser: unknown option (policy-features)
in config file.
Warning from /tmp/core20.profile (/etc/apparmor.d/abstractions/base line 13):
/snap/core20/current/sbin/apparmor_parser: Profile abi not supported, falling
back to system abi.
$ sudo aa-status | grep test-core20
test-core20-parser
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898038
Title:
docker-support/multipass-support broken with system apparmor3 (20.10)
To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1898038/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1898038] [NEW] docker-support/multipass-support broken with system apparmor3 (20.10)
Public bug reported:
The docker-support and multipass-support interfaces allow access to
/sbin/apparmor_parser.
/sbin/apparmor_parser is supplied by the core, core18 and core20 base
snaps.
/etc/apparmor* comes from the host, which on groovy has apparmor3.
Snaps using docker-support and multipass-support are completely broken
on groovy when using core and core18. On core20, policy loads with
warnings.
Transparent solution is to ship the /etc/apparmor and /etc/apparmor.d in
the base snaps, and bind mount these into place (eg, via snap-confine).
Snaps can fix themselves with layouts.
Note, there are plans to vendor apparmor3 into snapd for cross-distro
support and that will happen in the 21.04 cycle. However, that doesn't
fix snaps that plugs docker-support and multipass-support and load their
own policy.
# core
$ cat /tmp/core.profile
#include
profile test-core-profile {
#include
}
$ sudo /snap/core/current/sbin/apparmor_parser -r /tmp/core.profile
/snap/core/current/sbin/apparmor_parser: unknown option (policy-features) in
config file.
AppArmor parser error for /tmp/core.profile in /etc/apparmor.d/tunables/etc at
line 25: Could not open 'if'
[1]
$ sudo aa-status | grep test-core
[1]
# core18
$ cat /tmp/core18.profile
#include
profile test-core18-parser {
#include
}
$ sudo /snap/core18/current/sbin/apparmor_parser -r /tmp/core18.profile
/snap/core18/current/sbin/apparmor_parser: unknown option (policy-features) in
config file.
AppArmor parser error for /tmp/core18.profile in /etc/apparmor.d/tunables/etc
at line 25: Could not open 'if'
[1]
$ sudo aa-status | grep test-core18
[1]
# core20
$ cat /tmp/core20.profile
#include
profile test-core20-parser {
#include
}
$ sudo /snap/core20/current/sbin/apparmor_parser -r /tmp/core20.profile
/snap/core20/current/sbin/apparmor_parser: unknown option (policy-features) in
config file.
Warning from /tmp/core20.profile (/etc/apparmor.d/abstractions/base line 13):
/snap/core20/current/sbin/apparmor_parser: Profile abi not supported, falling
back to system abi.
$ sudo aa-status | grep test-core20
test-core20-parser
** Affects: snapd
Importance: Critical
Assignee: Alex Murray (alexmurray)
Status: Triaged
** Affects: snapd (Ubuntu)
Importance: Critical
Status: Triaged
** Changed in: snapd
Status: New => Triaged
** Changed in: snapd
Importance: Undecided => Critical
** Changed in: snapd
Assignee: (unassigned) => Alex Murray (alexmurray)
** Also affects: snapd (Ubuntu)
Importance: Undecided
Status: New
** Changed in: snapd (Ubuntu)
Status: New => Triaged
** Changed in: snapd (Ubuntu)
Importance: Undecided => Critical
** Changed in: snapd (Ubuntu)
Milestone: None => ubuntu-20.10
** Description changed:
The docker-support and multipass-support interfaces allow access to
/sbin/apparmor_parser.
/sbin/apparmor_parser is supplied by the core, core18 and core20 base
snaps.
/etc/apparmor* comes from the host, which on groovy has apparmor3.
Snaps using docker-support and multipass-support are completely broken
on groovy when using core and core18. On core20, policy loads with
warnings.
Transparent solution is to ship the /etc/apparmor and /etc/apparmor.d in
the base snaps, and bind mount these into place (eg, via snap-confine).
Snaps can fix themselves with layouts.
Note, there are plans to vendor apparmor3 into snapd for cross-distro
support and that will happen in the 21.04 cycle. However, that doesn't
- fix snaps that plugs docker-support and multipass-support.
-
+ fix snaps that plugs docker-support and multipass-support and load their
+ own policy.
# core
- $ cat /tmp/core.profile
+ $ cat /tmp/core.profile
#include
profile test-core-profile {
- #include
-
+ #include
}
$ sudo /snap/core/current/sbin/apparmor_parser -r /tmp/core.profile
/snap/core/current/sbin/apparmor_parser: unknown option (policy-features) in
config file.
AppArmor parser error for /tmp/core.profile in /etc/apparmor.d/tunables/etc
at line 25: Could not open 'if'
[1]
$ sudo aa-status | grep test-core
[1]
-
# core18
- $ cat /tmp/core18.profile
+ $ cat /tmp/core18.profile
#include
profile test-core18-parser {
- #include
-
+ #include
}
$ sudo /snap/core18/current/sbin/apparmor_parser -r /tmp/core18.profile
/snap/core18/current/sbin/apparmor_parser: unknown option (policy-features)
in config file.
AppArmor parser error for /tmp/core18.profile in /etc/apparmor.d/tunables/etc
at line 25: Could not open 'if'
[1]
$ sudo aa-status | grep test-core18
[1]
-
# core20
- $ cat /tmp/core20.profile
+ $ cat /tmp/core20.profile
#include
profile test-core20-parser {
- #include
-
+ #include
}
$ sudo /snap/core20/current/sbin/apparmor_parser -r /tmp/core20.profile
/snap/core20/current/sbin/apparmor_parser: unknown option (policy-features)
in
[Bug 1894195] Re: FFe: Merge iptables 1.8.5-3 (main) from Debian sid (main)
** Changed in: iptables (Ubuntu) Status: New => Fix Committed ** Changed in: iptables (Ubuntu) Assignee: (unassigned) => Alex Murray (alexmurray) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1894195 Title: FFe: Merge iptables 1.8.5-3 (main) from Debian sid (main) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1894195/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1890835] Re: secureboot-db 2020 update
"Yes, ESM will be poked after other series release this." Dimitri - do we plan to respin trusty media with the upgraded grub? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1890835 Title: secureboot-db 2020 update To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/secureboot-db/+bug/1890835/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1887577] Re: DEP8: Invalid capability setuid
Removed the update_excuse and update_excuses tags based on Steve and Alex's comments. ** Tags removed: update-excuse update-excuses -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1887577 Title: DEP8: Invalid capability setuid To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1887577/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore
FYI, I removed the block-proposed tag since ubuntu6 fixes this bug. ** Tags removed: block-proposed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1895967 Title: Apparmor 3.0.0 does not load profiles in containers anymore To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore
I uploaded 3.0.0~beta1-0ubuntu6 just now that should address this issue. Thanks Christian for your debugging! ** Changed in: apparmor (Ubuntu) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1895967 Title: Apparmor 3.0.0 does not load profiles in containers anymore To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1871148] Re: services start before apparmor profiles are loaded
This was fixed in snapd in 2.44 via https://github.com/snapcore/snapd/pull/8467 ** Changed in: snapd (Ubuntu) Status: In Progress => Fix Released ** Changed in: snapd (Ubuntu Focal) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1871148 Title: services start before apparmor profiles are loaded To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1871148/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore
** Changed in: apparmor (Ubuntu) Status: Confirmed => In Progress ** Changed in: apparmor (Ubuntu) Assignee: (unassigned) => Jamie Strandboge (jdstrand) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1895967 Title: Apparmor 3.0.0 does not load profiles in containers anymore To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1895060] Re: [FFe] apparmor 3 upstream release
FYI, there was a components mismatch where apparmor-notify pulled python3-notify2 (and its Depends) into main. For now, I've demoted apparmor-notify to universe and adjusted the seed (in practical terms, the security team will fix bugs in apparmor-notify regardless of where it lives). We might revisit promoting apparmor-notify at a future date. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1895060 Title: [FFe] apparmor 3 upstream release To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1895060] Re: [FFe] apparmor 3 upstream release
Thanks! Uploaded: https://launchpad.net/ubuntu/+source/apparmor/3.0.0~beta1-0ubuntu5 ** Changed in: apparmor (Ubuntu) Status: Confirmed => Fix Committed ** Changed in: apparmor (Ubuntu) Assignee: (unassigned) => Alex Murray (alexmurray) ** Changed in: apparmor (Ubuntu) Milestone: None => ubuntu-20.10 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1895060 Title: [FFe] apparmor 3 upstream release To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1895060] Re: [FFe] apparmor 3 upstream release
FYI, I accidentally violated the FFe process and uploaded (with a subsequent binary copy) to groovy-proposed. None of that migrated, so I deleted what was in groovy-proposed and am now attaching the debdiff, which has patches to pass proposed migration (we believe). Sorry for the snafu. ** Patch added: "apparmor_2.13.3-7ubuntu6_to_3.0.0~beta1-0ubuntu5.debdiff" https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+attachment/5412212/+files/apparmor_2.13.3-7ubuntu6_to_3.0.0~beta1-0ubuntu5.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1895060 Title: [FFe] apparmor 3 upstream release To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1895060] Re: [FFe] apparmor 3 upstream release
FYI, 3.0.0~beta1-0ubuntu3 should address the dbus autopkgtest issue. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1895060 Title: [FFe] apparmor 3 upstream release To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
