[Touch-packages] [Bug 1970731] Re: iptables empty when using firewalld

2022-04-28 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1970731

Title:
  iptables empty when using firewalld

Status in firewalld package in Ubuntu:
  Invalid

Bug description:
  Summary:
  I am using firewalld/jammy,now 1.1.1-1ubuntu1 on my vpn server. The vpn 
server is using wireguard and I could successfully configure zones and policies 
in firewalld. Yet, iptables does not show the rules from firewalld.

  1) System
  root@vpn:~# uname -a
  Linux vpn 5.15.0-27-generic #28-Ubuntu SMP Thu Apr 14 04:55:28 UTC 2022 
x86_64 x86_64 x86_64 GNU/Linux
  root@vpn:~# lsb_release -rd
  Description:  Ubuntu 22.04 LTS
  Release:  22.04

  All updates installed.

  
  2) What happens:

  I am setting rules with firewall-cmd.

  These firewall rules are visible with:
 nft list table inet firewalld
  but not with 'iptables'.

  3) What I expect to happen:

  The toutput of
iptables --list
  should also reflect firewalld settings.

  4) What happened instead

  However, the iptables output shows only empty tables (filter, mangle,
  nat).

  root@vpn:~# iptables -t nat --list
  # Warning: iptables-legacy tables present, use iptables-legacy to see them
  Chain PREROUTING (policy ACCEPT)
  target prot opt source   destination 

  Chain INPUT (policy ACCEPT)
  target prot opt source   destination 

  Chain OUTPUT (policy ACCEPT)
  target prot opt source   destination 

  Chain POSTROUTING (policy ACCEPT)
  target prot opt source   destination 
  root@vpn:~# iptables -t filter --list
  # Warning: iptables-legacy tables present, use iptables-legacy to see them
  Chain INPUT (policy ACCEPT)
  target prot opt source   destination 

  Chain FORWARD (policy ACCEPT)
  target prot opt source   destination 

  Chain OUTPUT (policy ACCEPT)
  target prot opt source   destination 
  root@vpn:~# iptables-legacy -t nat --list
  Chain PREROUTING (policy ACCEPT)
  target prot opt source   destination 

  Chain INPUT (policy ACCEPT)
  target prot opt source   destination 

  Chain OUTPUT (policy ACCEPT)
  target prot opt source   destination 

  Chain POSTROUTING (policy ACCEPT)
  target prot opt source   destination 
  root@vpn:~# iptables-legacy -t filter --list
  Chain INPUT (policy ACCEPT)
  target prot opt source   destination 

  Chain FORWARD (policy ACCEPT)
  target prot opt source   destination 

  Chain OUTPUT (policy ACCEPT)
  target prot opt source   destination 

  
  5) Further information

  The ufw firewall is disabled and uninstalled.

  According to the release notes of 22.04, the backend has changed to nftables. 
  I was assuming, that the backend default is kind of transparent to the user, 
meaning iptables should still work as normal. 

  I wonder if on my system is iptables correctly linked to the backend.

  Iptables points to xtables-nft-multi:
  root@vpn:~# ls -l /usr/sbin/iptables
  lrwxrwxrwx 1 root root 26 Aug 24  2021 /usr/sbin/iptables -> 
/etc/alternatives/iptables
  root@vpn:~# ls -l /etc/alternatives/iptables
  lrwxrwxrwx 1 root root 22 Apr 25 18:56 /etc/alternatives/iptables -> 
/usr/sbin/iptables-nft
  root@vpn:~# ls -l /usr/sbin/iptables-nft
  lrwxrwxrwx 1 root root 17 Mar 24 12:58 /usr/sbin/iptables-nft -> 
xtables-nft-multi
  root@vpn:~# ls -l /usr/sbin/xtables-nft-multi
  -rwxr-xr-x 1 root root 224296 Mar 24 12:58 /usr/sbin/xtables-nft-multi

  
  Perhaps this is an issue with the upgrade process of ubuntu.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/firewalld/+bug/1970731/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1896772] Re: systemd-resolved configures no Current Scopes on start

2022-04-18 Thread Jamie Strandboge
** Changed in: isc-dhcp (Ubuntu)
   Status: New => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1896772

Title:
  systemd-resolved configures no Current Scopes on start

Status in ifupdown package in Ubuntu:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Running groovy on the desktop, with the systemd packages that migrated
  today(/overnight EDT).

  # Steps to reproduce:

  1) `systemctl restart systemd-resolved.service`

  (This is a minimal reproducer, but I first saw this after an apt
  upgrade of systemd.)

  # Expected behaviour:

  DNS continues to work, status looks like this:

  Link 2 (enp5s0)
Current Scopes: DNS
  DefaultRoute setting: yes
 LLMNR setting: yes
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no
Current DNS Server: 192.168.1.1
   DNS Servers: 192.168.1.1
DNS Domain: ~.
lan

  # Actual behaviour:

  DNS is unconfigured:

  Link 2 (enp5s0)
Current Scopes: none
  DefaultRoute setting: no
 LLMNR setting: yes
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no

  # Workaround

  Disconnecting and reconnecting my network connection restored DNS
  functionality.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: systemd 246.5-1ubuntu1
  ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4
  Uname: Linux 5.8.0-18-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset 
nvidia
  ApportVersion: 2.20.11-0ubuntu45
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: i3
  CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read 
kernel buffer failed: Operation not permitted
  Date: Wed Sep 23 09:05:42 2020
  InstallationDate: Installed on 2019-05-07 (504 days ago)
  InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  MachineType: Gigabyte Technology Co., Ltd. B450M DS3H
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-18-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash 
resume=UUID=73909634-a75d-42c9-8f66-a69138690756 pcie_aspm=off vt.handoff=7
  RebootRequiredPkgs: gnome-shell
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /lib/systemd/system/rc-local.service → 
/lib/systemd/system/rc-local.service.d/debian.conf
   [EXTENDED]   /lib/systemd/system/user@.service → 
/lib/systemd/system/user@.service.d/timeout.conf
   
   2 overridden configuration files found.
  SystemdFailedUnits:
   Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 
4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use 
systemd-escape?).
   Unit \xe2\x97\x8f.service could not be found.
   --
   Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 
4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use 
systemd-escape?).
   Unit \xe2\x97\x8f.service could not be found.
  UpgradeStatus: Upgraded to groovy on 2020-06-22 (92 days ago)
  dmi.bios.date: 01/25/2019
  dmi.bios.release: 5.13
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: F4
  dmi.board.asset.tag: Default string
  dmi.board.name: B450M DS3H-CF
  dmi.board.vendor: Gigabyte Technology Co., Ltd.
  dmi.board.version: x.x
  dmi.chassis.asset.tag: Default string
  dmi.chassis.type: 3
  dmi.chassis.vendor: Default string
  dmi.chassis.version: Default string
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrF4:bd01/25/2019:br5.13:svnGigabyteTechnologyCo.,Ltd.:pnB450MDS3H:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450MDS3H-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring:
  dmi.product.family: Default string
  dmi.product.name: B450M DS3H
  dmi.product.sku: Default string
  dmi.product.version: Default string
  dmi.sys.vendor: Gigabyte Technology Co., Ltd.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1896772/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1896772] Re: systemd-resolved configures no Current Scopes on start

2022-04-17 Thread Jamie Strandboge
** Changed in: ifupdown (Ubuntu)
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1896772

Title:
  systemd-resolved configures no Current Scopes on start

Status in ifupdown package in Ubuntu:
  In Progress
Status in isc-dhcp package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Running groovy on the desktop, with the systemd packages that migrated
  today(/overnight EDT).

  # Steps to reproduce:

  1) `systemctl restart systemd-resolved.service`

  (This is a minimal reproducer, but I first saw this after an apt
  upgrade of systemd.)

  # Expected behaviour:

  DNS continues to work, status looks like this:

  Link 2 (enp5s0)
Current Scopes: DNS
  DefaultRoute setting: yes
 LLMNR setting: yes
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no
Current DNS Server: 192.168.1.1
   DNS Servers: 192.168.1.1
DNS Domain: ~.
lan

  # Actual behaviour:

  DNS is unconfigured:

  Link 2 (enp5s0)
Current Scopes: none
  DefaultRoute setting: no
 LLMNR setting: yes
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no

  # Workaround

  Disconnecting and reconnecting my network connection restored DNS
  functionality.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: systemd 246.5-1ubuntu1
  ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4
  Uname: Linux 5.8.0-18-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset 
nvidia
  ApportVersion: 2.20.11-0ubuntu45
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: i3
  CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read 
kernel buffer failed: Operation not permitted
  Date: Wed Sep 23 09:05:42 2020
  InstallationDate: Installed on 2019-05-07 (504 days ago)
  InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  MachineType: Gigabyte Technology Co., Ltd. B450M DS3H
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-18-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash 
resume=UUID=73909634-a75d-42c9-8f66-a69138690756 pcie_aspm=off vt.handoff=7
  RebootRequiredPkgs: gnome-shell
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /lib/systemd/system/rc-local.service → 
/lib/systemd/system/rc-local.service.d/debian.conf
   [EXTENDED]   /lib/systemd/system/user@.service → 
/lib/systemd/system/user@.service.d/timeout.conf
   
   2 overridden configuration files found.
  SystemdFailedUnits:
   Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 
4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use 
systemd-escape?).
   Unit \xe2\x97\x8f.service could not be found.
   --
   Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 
4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use 
systemd-escape?).
   Unit \xe2\x97\x8f.service could not be found.
  UpgradeStatus: Upgraded to groovy on 2020-06-22 (92 days ago)
  dmi.bios.date: 01/25/2019
  dmi.bios.release: 5.13
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: F4
  dmi.board.asset.tag: Default string
  dmi.board.name: B450M DS3H-CF
  dmi.board.vendor: Gigabyte Technology Co., Ltd.
  dmi.board.version: x.x
  dmi.chassis.asset.tag: Default string
  dmi.chassis.type: 3
  dmi.chassis.vendor: Default string
  dmi.chassis.version: Default string
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrF4:bd01/25/2019:br5.13:svnGigabyteTechnologyCo.,Ltd.:pnB450MDS3H:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450MDS3H-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring:
  dmi.product.family: Default string
  dmi.product.name: B450M DS3H
  dmi.product.sku: Default string
  dmi.product.version: Default string
  dmi.sys.vendor: Gigabyte Technology Co., Ltd.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1896772/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1896772] Re: systemd-resolved configures no Current Scopes on start

2022-04-17 Thread Jamie Strandboge
** 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
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1896772

Title:
  systemd-resolved configures no Current Scopes on start

Status in ifupdown package in Ubuntu:
  New
Status in isc-dhcp package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Running groovy on the desktop, with the systemd packages that migrated
  today(/overnight EDT).

  # Steps to reproduce:

  1) `systemctl restart systemd-resolved.service`

  (This is a minimal reproducer, but I first saw this after an apt
  upgrade of systemd.)

  # Expected behaviour:

  DNS continues to work, status looks like this:

  Link 2 (enp5s0)
Current Scopes: DNS
  DefaultRoute setting: yes
 LLMNR setting: yes
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no
Current DNS Server: 192.168.1.1
   DNS Servers: 192.168.1.1
DNS Domain: ~.
lan

  # Actual behaviour:

  DNS is unconfigured:

  Link 2 (enp5s0)
Current Scopes: none
  DefaultRoute setting: no
 LLMNR setting: yes
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no

  # Workaround

  Disconnecting and reconnecting my network connection restored DNS
  functionality.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: systemd 246.5-1ubuntu1
  ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4
  Uname: Linux 5.8.0-18-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset 
nvidia
  ApportVersion: 2.20.11-0ubuntu45
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: i3
  CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read 
kernel buffer failed: Operation not permitted
  Date: Wed Sep 23 09:05:42 2020
  InstallationDate: Installed on 2019-05-07 (504 days ago)
  InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  MachineType: Gigabyte Technology Co., Ltd. B450M DS3H
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-18-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash 
resume=UUID=73909634-a75d-42c9-8f66-a69138690756 pcie_aspm=off vt.handoff=7
  RebootRequiredPkgs: gnome-shell
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /lib/systemd/system/rc-local.service → 
/lib/systemd/system/rc-local.service.d/debian.conf
   [EXTENDED]   /lib/systemd/system/user@.service → 
/lib/systemd/system/user@.service.d/timeout.conf
   
   2 overridden configuration files found.
  SystemdFailedUnits:
   Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 
4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use 
systemd-escape?).
   Unit \xe2\x97\x8f.service could not be found.
   --
   Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 
4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use 
systemd-escape?).
   Unit \xe2\x97\x8f.service could not be found.
  UpgradeStatus: Upgraded to groovy on 2020-06-22 (92 days ago)
  dmi.bios.date: 01/25/2019
  dmi.bios.release: 5.13
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: F4
  dmi.board.asset.tag: Default string
  dmi.board.name: B450M DS3H-CF
  dmi.board.vendor: Gigabyte Technology Co., Ltd.
  dmi.board.version: x.x
  dmi.chassis.asset.tag: Default string
  dmi.chassis.type: 3
  dmi.chassis.vendor: Default string
  dmi.chassis.version: Default string
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrF4:bd01/25/2019:br5.13:svnGigabyteTechnologyCo.,Ltd.:pnB450MDS3H:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450MDS3H-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring:
  dmi.product.family: Default string
  dmi.product.name: B450M DS3H
  dmi.product.sku: Default string
  dmi.product.version: Default string
  dmi.sys.vendor: Gigabyte Technology Co., Ltd.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1896772/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1896772] Re: systemd-resolved configures no Current Scopes on start

2022-04-17 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1896772

Title:
  systemd-resolved configures no Current Scopes on start

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Running groovy on the desktop, with the systemd packages that migrated
  today(/overnight EDT).

  # Steps to reproduce:

  1) `systemctl restart systemd-resolved.service`

  (This is a minimal reproducer, but I first saw this after an apt
  upgrade of systemd.)

  # Expected behaviour:

  DNS continues to work, status looks like this:

  Link 2 (enp5s0)
Current Scopes: DNS
  DefaultRoute setting: yes
 LLMNR setting: yes
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no
Current DNS Server: 192.168.1.1
   DNS Servers: 192.168.1.1
DNS Domain: ~.
lan

  # Actual behaviour:

  DNS is unconfigured:

  Link 2 (enp5s0)
Current Scopes: none
  DefaultRoute setting: no
 LLMNR setting: yes
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no

  # Workaround

  Disconnecting and reconnecting my network connection restored DNS
  functionality.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: systemd 246.5-1ubuntu1
  ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4
  Uname: Linux 5.8.0-18-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset 
nvidia
  ApportVersion: 2.20.11-0ubuntu45
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: i3
  CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read 
kernel buffer failed: Operation not permitted
  Date: Wed Sep 23 09:05:42 2020
  InstallationDate: Installed on 2019-05-07 (504 days ago)
  InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  MachineType: Gigabyte Technology Co., Ltd. B450M DS3H
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-18-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash 
resume=UUID=73909634-a75d-42c9-8f66-a69138690756 pcie_aspm=off vt.handoff=7
  RebootRequiredPkgs: gnome-shell
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /lib/systemd/system/rc-local.service → 
/lib/systemd/system/rc-local.service.d/debian.conf
   [EXTENDED]   /lib/systemd/system/user@.service → 
/lib/systemd/system/user@.service.d/timeout.conf
   
   2 overridden configuration files found.
  SystemdFailedUnits:
   Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 
4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use 
systemd-escape?).
   Unit \xe2\x97\x8f.service could not be found.
   --
   Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 
4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use 
systemd-escape?).
   Unit \xe2\x97\x8f.service could not be found.
  UpgradeStatus: Upgraded to groovy on 2020-06-22 (92 days ago)
  dmi.bios.date: 01/25/2019
  dmi.bios.release: 5.13
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: F4
  dmi.board.asset.tag: Default string
  dmi.board.name: B450M DS3H-CF
  dmi.board.vendor: Gigabyte Technology Co., Ltd.
  dmi.board.version: x.x
  dmi.chassis.asset.tag: Default string
  dmi.chassis.type: 3
  dmi.chassis.vendor: Default string
  dmi.chassis.version: Default string
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrF4:bd01/25/2019:br5.13:svnGigabyteTechnologyCo.,Ltd.:pnB450MDS3H:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450MDS3H-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring:
  dmi.product.family: Default string
  dmi.product.name: B450M DS3H
  dmi.product.sku: Default string
  dmi.product.version: Default string
  dmi.sys.vendor: Gigabyte Technology Co., Ltd.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896772/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net

[Touch-packages] [Bug 1896772] Re: systemd-resolved configures no Current Scopes on start

2022-04-17 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1896772

Title:
  systemd-resolved configures no Current Scopes on start

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Running groovy on the desktop, with the systemd packages that migrated
  today(/overnight EDT).

  # Steps to reproduce:

  1) `systemctl restart systemd-resolved.service`

  (This is a minimal reproducer, but I first saw this after an apt
  upgrade of systemd.)

  # Expected behaviour:

  DNS continues to work, status looks like this:

  Link 2 (enp5s0)
Current Scopes: DNS
  DefaultRoute setting: yes
 LLMNR setting: yes
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no
Current DNS Server: 192.168.1.1
   DNS Servers: 192.168.1.1
DNS Domain: ~.
lan

  # Actual behaviour:

  DNS is unconfigured:

  Link 2 (enp5s0)
Current Scopes: none
  DefaultRoute setting: no
 LLMNR setting: yes
  MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
  DNSSEC supported: no

  # Workaround

  Disconnecting and reconnecting my network connection restored DNS
  functionality.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: systemd 246.5-1ubuntu1
  ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4
  Uname: Linux 5.8.0-18-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset 
nvidia
  ApportVersion: 2.20.11-0ubuntu45
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: i3
  CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read 
kernel buffer failed: Operation not permitted
  Date: Wed Sep 23 09:05:42 2020
  InstallationDate: Installed on 2019-05-07 (504 days ago)
  InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  MachineType: Gigabyte Technology Co., Ltd. B450M DS3H
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-18-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash 
resume=UUID=73909634-a75d-42c9-8f66-a69138690756 pcie_aspm=off vt.handoff=7
  RebootRequiredPkgs: gnome-shell
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /lib/systemd/system/rc-local.service → 
/lib/systemd/system/rc-local.service.d/debian.conf
   [EXTENDED]   /lib/systemd/system/user@.service → 
/lib/systemd/system/user@.service.d/timeout.conf
   
   2 overridden configuration files found.
  SystemdFailedUnits:
   Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 
4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use 
systemd-escape?).
   Unit \xe2\x97\x8f.service could not be found.
   --
   Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 
4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use 
systemd-escape?).
   Unit \xe2\x97\x8f.service could not be found.
  UpgradeStatus: Upgraded to groovy on 2020-06-22 (92 days ago)
  dmi.bios.date: 01/25/2019
  dmi.bios.release: 5.13
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: F4
  dmi.board.asset.tag: Default string
  dmi.board.name: B450M DS3H-CF
  dmi.board.vendor: Gigabyte Technology Co., Ltd.
  dmi.board.version: x.x
  dmi.chassis.asset.tag: Default string
  dmi.chassis.type: 3
  dmi.chassis.vendor: Default string
  dmi.chassis.version: Default string
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrF4:bd01/25/2019:br5.13:svnGigabyteTechnologyCo.,Ltd.:pnB450MDS3H:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450MDS3H-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring:
  dmi.product.family: Default string
  dmi.product.name: B450M DS3H
  dmi.product.sku: Default string
  dmi.product.version: Default string
  dmi.sys.vendor: Gigabyte Technology Co., Ltd.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896772/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1968608] Re: networking/firewall issues after upgrade when using iptables-nft

2022-04-11 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1968608

Title:
  networking/firewall issues after upgrade when using iptables-nft

Status in ufw:
  Invalid
Status in iptables package in Ubuntu:
  Invalid
Status in ufw package in Ubuntu:
  Invalid

Bug description:
  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 

[Touch-packages] [Bug 1968608] Re: networking/firewall issues after upgrade when using iptables-nft

2022-04-11 Thread Jamie Strandboge
** 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 

[Touch-packages] [Bug 1968608] [NEW] networking/firewall issues after upgrade when using iptables-nft

2022-04-11 Thread Jamie Strandboge
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 

[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network

2022-01-05 Thread Jamie Strandboge
** Tags removed: block-proposed block-proposed-jammy

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1950039

Title:
  ufw 0.36.1-3 introduces ordering cycle, breaking network

Status in cloud-init package in Ubuntu:
  Invalid
Status in ufw package in Ubuntu:
  Triaged

Bug description:

   [2.065178] systemd[1]: 
systemd-networkd.service: Found ordering cycle on network-pre.target/start

   [2.065276] systemd[1]: 
systemd-networkd.service: Found dependency on ufw.service/start

   [2.065356] systemd[1]: 
systemd-networkd.service: Found dependency on basic.target/start

   [2.065422] systemd[1]: 
systemd-networkd.service: Found dependency on sockets.target/start

   [2.065487] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star
  t

   [2.065561] systemd[1]: 
systemd-networkd.service: Found dependency on sysinit.target/start

   [2.065626] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init.service/start

   [2.065700] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se
  rvice/start

   [2.065795] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd.service/start

   [2.065870] systemd[1]: 
systemd-networkd.service: Job network-pre.target/start deleted to break 
ordering cycle starting with systemd-networkd.service/start

   [[0;1;31m SKIP [0m] Ordering cycle found, 
skipping [0;1;39mNetwork (Pre)[0m

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1950039/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network

2022-01-05 Thread Jamie Strandboge
https://launchpad.net/ubuntu/+source/ufw/0.36.1-3ubuntu1

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1950039

Title:
  ufw 0.36.1-3 introduces ordering cycle, breaking network

Status in cloud-init package in Ubuntu:
  Invalid
Status in ufw package in Ubuntu:
  Triaged

Bug description:

   [2.065178] systemd[1]: 
systemd-networkd.service: Found ordering cycle on network-pre.target/start

   [2.065276] systemd[1]: 
systemd-networkd.service: Found dependency on ufw.service/start

   [2.065356] systemd[1]: 
systemd-networkd.service: Found dependency on basic.target/start

   [2.065422] systemd[1]: 
systemd-networkd.service: Found dependency on sockets.target/start

   [2.065487] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star
  t

   [2.065561] systemd[1]: 
systemd-networkd.service: Found dependency on sysinit.target/start

   [2.065626] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init.service/start

   [2.065700] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se
  rvice/start

   [2.065795] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd.service/start

   [2.065870] systemd[1]: 
systemd-networkd.service: Job network-pre.target/start deleted to break 
ordering cycle starting with systemd-networkd.service/start

   [[0;1;31m SKIP [0m] Ordering cycle found, 
skipping [0;1;39mNetwork (Pre)[0m

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1950039/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network

2022-01-05 Thread Jamie Strandboge
** 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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1950039

Title:
  ufw 0.36.1-3 introduces ordering cycle, breaking network

Status in cloud-init package in Ubuntu:
  Invalid
Status in ufw package in Ubuntu:
  Triaged

Bug description:

   [2.065178] systemd[1]: 
systemd-networkd.service: Found ordering cycle on network-pre.target/start

   [2.065276] systemd[1]: 
systemd-networkd.service: Found dependency on ufw.service/start

   [2.065356] systemd[1]: 
systemd-networkd.service: Found dependency on basic.target/start

   [2.065422] systemd[1]: 
systemd-networkd.service: Found dependency on sockets.target/start

   [2.065487] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star
  t

   [2.065561] systemd[1]: 
systemd-networkd.service: Found dependency on sysinit.target/start

   [2.065626] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init.service/start

   [2.065700] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se
  rvice/start

   [2.065795] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd.service/start

   [2.065870] systemd[1]: 
systemd-networkd.service: Job network-pre.target/start deleted to break 
ordering cycle starting with systemd-networkd.service/start

   [[0;1;31m SKIP [0m] Ordering cycle found, 
skipping [0;1;39mNetwork (Pre)[0m

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1950039/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network

2022-01-05 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1950039

Title:
  ufw 0.36.1-3 introduces ordering cycle, breaking network

Status in cloud-init package in Ubuntu:
  Invalid
Status in ufw package in Ubuntu:
  Triaged

Bug description:

   [2.065178] systemd[1]: 
systemd-networkd.service: Found ordering cycle on network-pre.target/start

   [2.065276] systemd[1]: 
systemd-networkd.service: Found dependency on ufw.service/start

   [2.065356] systemd[1]: 
systemd-networkd.service: Found dependency on basic.target/start

   [2.065422] systemd[1]: 
systemd-networkd.service: Found dependency on sockets.target/start

   [2.065487] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star
  t

   [2.065561] systemd[1]: 
systemd-networkd.service: Found dependency on sysinit.target/start

   [2.065626] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init.service/start

   [2.065700] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se
  rvice/start

   [2.065795] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd.service/start

   [2.065870] systemd[1]: 
systemd-networkd.service: Job network-pre.target/start deleted to break 
ordering cycle starting with systemd-networkd.service/start

   [[0;1;31m SKIP [0m] Ordering cycle found, 
skipping [0;1;39mNetwork (Pre)[0m

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1950039/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1956029] Re: ufw remains inactive at boot time

2022-01-04 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1956029

Title:
  ufw remains inactive at boot time

Status in ufw package in Ubuntu:
  Invalid

Bug description:
  I was advised to start a bug report (Comment 38):
  https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856

  I "ufw enable" then several seconds later networking stops. I have get
  Ubuntu to gracefully power-down using the power-button and then
  gracefully power-up.

  Out of curiosity, is anyone here having this problem wish ufw starting
  up at boot time while also using having fail2ban installed?

  Here is my theory. It takes a while for fail2ban to issue all the
  iptable commands to configure the firewall. When ufw tries to
  initialise there may be a clash or lock held either by an iptables
  instance spawned by fail2ban or an iptables instance spawned by ufw.
  One of them will fail and will quite probably mess-up ufw's rules
  breaking network connectivity.

  This time I waited for fail2ban to finish establishing its iptables
  rules before issuing "ufw enable" and this time round network
  connectivity was not lost.

  How to I ensure that ufw is fully up and initialised BEFORE the
  fail2ban service starts?

  -
  root@loki:~# ./ufw-diag.sh
  Has python: pass (binary: python3, version: 3.8.10, py3)
  Has iptables: pass
  Has ip6tables: pass

  Has /proc/net/dev: pass
  Has /proc/net/if_inet6: pass

  This script will now attempt to create various rules using the iptables
  and ip6tables commands. This may result in module autoloading (eg, for
  IPv6).
  Proceed with checks (Y/n)?
  == IPv4 ==
  Creating 'ufw-check-requirements'... done
  Inserting RETURN at top of 'ufw-check-requirements'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: pass
  LOG: pass
  hashlimit: pass
  limit: pass
  ctstate (NEW): pass
  ctstate (RELATED): pass
  ctstate (ESTABLISHED): pass
  ctstate (INVALID): pass
  ctstate (new, recent set): pass
  ctstate (new, recent update): pass
  ctstate (new, limit): pass
  interface (input): pass
  interface (output): pass
  multiport: pass
  comment: pass
  addrtype (LOCAL): pass
  addrtype (MULTICAST): pass
  addrtype (BROADCAST): pass
  icmp (destination-unreachable): pass
  icmp (source-quench): pass
  icmp (time-exceeded): pass
  icmp (parameter-problem): pass
  icmp (echo-request): pass

  == IPv6 ==
  Creating 'ufw-check-requirements6'... done
  Inserting RETURN at top of 'ufw-check-requirements6'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: pass
  LOG: pass
  hashlimit: pass
  limit: pass
  ctstate (NEW): pass
  ctstate (RELATED): pass
  ctstate (ESTABLISHED): pass
  ctstate (INVALID): pass
  ctstate (new, recent set): pass
  ctstate (new, recent update): pass
  ctstate (new, limit): pass
  interface (input): pass
  interface (output): pass
  multiport: pass
  comment: pass
  icmpv6 (destination-unreachable): pass
  icmpv6 (packet-too-big): pass
  icmpv6 (time-exceeded): pass
  icmpv6 (parameter-problem): pass
  icmpv6 (echo-request): pass
  icmpv6 with hl (neighbor-solicitation): pass
  icmpv6 with hl (neighbor-advertisement): pass
  icmpv6 with hl (router-solicitation): pass
  icmpv6 with hl (router-advertisement): pass
  ipv6 rt: pass

  All tests passed
  -
  root@loki:/lib/systemd/system# cat ufw.service
  [Unit]
  Description=Uncomplicated firewall
  Documentation=man:ufw(8)
  DefaultDependencies=no
  Before=network.target
  After=NetworkManager.service

  [Service]
  Type=oneshot
  RemainAfterExit=yes
  ExecStart=/lib/ufw/ufw-init start quiet
  # ExecStartPost=/bin/sleep 10
  ExecStop=/lib/ufw/ufw-init stop

  [Install]
  WantedBy=multi-user.target

  -
  root@loki:/lib/systemd/system# cat fail2ban.service
  [Unit]
  Description=Fail2Ban Service
  Documentation=man:fail2ban(1)
  After=network.target iptables.service firewalld.service ip6tables.service 
ipset.service nftables.service ufw.service
  PartOf=firewalld.service

  [Service]
  Type=simple
  ExecStartPre=/bin/mkdir -p /run/fail2ban
  ExecStart=/usr/bin/fail2ban-server -xf start
  # if should be logged in systemd journal, use following line or set logtarget 
to sysout in fail2ban.local
  # ExecStart=/usr/bin/fail2ban-server -xf --logtarget=sysout start
  ExecStop=/usr/bin/fail2ban-client stop
  ExecReload=/usr/bin/fail2ban-client reload
  PIDFile=/run/fail2ban/fail2ban.pid
  Restart=on-failure
  RestartPreventExitStatus=0 255

  [Install]
  WantedBy=multi-user.target

  -
  root@loki:/etc/default# cat ufw
  # /etc/default/ufw
  #

  # Set to yes to apply rules to support IPv6 (no 

[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network

2022-01-04 Thread Jamie Strandboge
> 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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1950039

Title:
  ufw 0.36.1-3 introduces ordering cycle, breaking network

Status in cloud-init package in Ubuntu:
  New
Status in ufw package in Ubuntu:
  New

Bug description:

   [2.065178] systemd[1]: 
systemd-networkd.service: Found ordering cycle on network-pre.target/start

   [2.065276] systemd[1]: 
systemd-networkd.service: Found dependency on ufw.service/start

   [2.065356] systemd[1]: 
systemd-networkd.service: Found dependency on basic.target/start

   [2.065422] systemd[1]: 
systemd-networkd.service: Found dependency on sockets.target/start

   [2.065487] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star
  t

   [2.065561] systemd[1]: 
systemd-networkd.service: Found dependency on sysinit.target/start

   [2.065626] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init.service/start

   [2.065700] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se
  rvice/start

   [2.065795] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd.service/start

   [2.065870] systemd[1]: 
systemd-networkd.service: Job network-pre.target/start deleted to break 
ordering cycle starting with systemd-networkd.service/start

   [[0;1;31m SKIP [0m] Ordering cycle found, 
skipping [0;1;39mNetwork (Pre)[0m

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1950039/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network

2022-01-04 Thread Jamie Strandboge
> 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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1950039

Title:
  ufw 0.36.1-3 introduces ordering cycle, breaking network

Status in cloud-init package in Ubuntu:
  New
Status in ufw package in Ubuntu:
  New

Bug description:

   [2.065178] systemd[1]: 
systemd-networkd.service: Found ordering cycle on network-pre.target/start

   [2.065276] systemd[1]: 
systemd-networkd.service: Found dependency on ufw.service/start

   [2.065356] systemd[1]: 
systemd-networkd.service: Found dependency on basic.target/start

   [2.065422] systemd[1]: 
systemd-networkd.service: Found dependency on sockets.target/start

   [2.065487] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star
  t

   [2.065561] systemd[1]: 
systemd-networkd.service: Found dependency on sysinit.target/start

   [2.065626] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init.service/start

   [2.065700] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se
  rvice/start

   [2.065795] systemd[1]: 
systemd-networkd.service: Found dependency on 

[Touch-packages] [Bug 1956029] Re: ufw remains inactive at boot time

2021-12-30 Thread Jamie Strandboge
> 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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1956029

Title:
  ufw remains inactive at boot time

Status in ufw package in Ubuntu:
  Incomplete

Bug description:
  I was advised to start a bug report (Comment 38):
  https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856

  I "ufw enable" then several seconds later networking stops. I have get
  Ubuntu to gracefully power-down using the power-button and then
  gracefully power-up.

  Out of curiosity, is anyone here having this problem wish ufw starting
  up at boot time while also using having fail2ban installed?

  Here is my theory. It takes a while for fail2ban to issue all the
  iptable commands to configure the firewall. When ufw tries to
  initialise there may be a clash or lock held either by an iptables
  instance spawned by fail2ban or an iptables instance spawned by ufw.
  One of them will fail and will quite probably mess-up ufw's rules
  breaking network connectivity.

  This time I waited for fail2ban to finish establishing its iptables
  rules before issuing "ufw enable" and this time round network
  connectivity was not lost.

  How to I ensure that ufw is fully up and initialised BEFORE the
  fail2ban service starts?

  -
  root@loki:~# ./ufw-diag.sh
  Has python: pass (binary: python3, version: 3.8.10, py3)
  Has iptables: pass
  Has ip6tables: pass

  Has /proc/net/dev: pass
  Has /proc/net/if_inet6: pass

  This script will now attempt to create various rules using the iptables
  and ip6tables commands. This may result in module autoloading (eg, for
  IPv6).
  Proceed with checks (Y/n)?
  == IPv4 ==
  Creating 'ufw-check-requirements'... done
  Inserting RETURN at top of 'ufw-check-requirements'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: pass
  LOG: pass
  hashlimit: pass
  limit: pass
  ctstate (NEW): pass
  ctstate (RELATED): pass
  ctstate (ESTABLISHED): pass
  ctstate (INVALID): pass
  ctstate (new, recent set): pass
  ctstate (new, recent update): pass
  ctstate (new, limit): pass
  interface (input): pass
  interface (output): pass
  multiport: pass
  comment: pass
  addrtype (LOCAL): pass
  addrtype (MULTICAST): pass
  addrtype (BROADCAST): pass
  icmp (destination-unreachable): pass
  icmp (source-quench): pass
  icmp (time-exceeded): pass
  icmp (parameter-problem): pass
  icmp (echo-request): pass

  == IPv6 ==
  Creating 'ufw-check-requirements6'... done
  Inserting RETURN at top of 'ufw-check-requirements6'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: pass
  LOG: pass
  hashlimit: pass
  limit: pass
  ctstate (NEW): pass
  ctstate (RELATED): pass
  ctstate (ESTABLISHED): pass
  ctstate (INVALID): pass
  ctstate (new, recent set): pass
  ctstate (new, recent update): pass
  ctstate (new, limit): pass
  interface (input): pass
  interface (output): pass
  multiport: pass
  comment: pass
  icmpv6 (destination-unreachable): pass
  icmpv6 (packet-too-big): pass
  icmpv6 (time-exceeded): pass
  icmpv6 (parameter-problem): pass
  icmpv6 (echo-request): pass
  icmpv6 with hl (neighbor-solicitation): pass
  icmpv6 with hl (neighbor-advertisement): pass
  icmpv6 with hl (router-solicitation): pass
  icmpv6 with hl (router-advertisement): pass
  ipv6 rt: pass

  All tests passed
  -
  root@loki:/lib/systemd/system# cat ufw.service
  [Unit]
  Description=Uncomplicated firewall
  Documentation=man:ufw(8)
  DefaultDependencies=no
  Before=network.target
  After=NetworkManager.service

  [Service]
  Type=oneshot
  RemainAfterExit=yes
  ExecStart=/lib/ufw/ufw-init start quiet
  # ExecStartPost=/bin/sleep 10
  ExecStop=/lib/ufw/ufw-init stop

  [Install]
  WantedBy=multi-user.target

  -
  root@loki:/lib/systemd/system# cat fail2ban.service
  [Unit]
  Description=Fail2Ban Service
  Documentation=man:fail2ban(1)
  After=network.target iptables.service firewalld.service ip6tables.service 
ipset.service nftables.service ufw.service
  PartOf=firewalld.service

  [Service]
  Type=simple
  ExecStartPre=/bin/mkdir -p /run/fail2ban
  ExecStart=/usr/bin/fail2ban-server -xf start
  # if should be logged in systemd journal, use following line or set logtarget 
to sysout in 

[Touch-packages] [Bug 1956029] Re: ufw remains inactive at boot time

2021-12-30 Thread Jamie Strandboge
> 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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1956029

Title:
  ufw remains inactive at boot time

Status in ufw package in Ubuntu:
  Incomplete

Bug description:
  I was advised to start a bug report (Comment 38):
  https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856

  I "ufw enable" then several seconds later networking stops. I have get
  Ubuntu to gracefully power-down using the power-button and then
  gracefully power-up.

  Out of curiosity, is anyone here having this problem wish ufw starting
  up at boot time while also using having fail2ban installed?

  Here is my theory. It takes a while for fail2ban to issue all the
  iptable commands to configure the firewall. When ufw tries to
  initialise there may be a clash or lock held either by an iptables
  instance spawned by fail2ban or an iptables instance spawned by ufw.
  One of them will fail and will quite probably mess-up ufw's rules
  breaking network connectivity.

  This time I waited for fail2ban to finish establishing its iptables
  rules before issuing "ufw enable" and this time round network
  connectivity was not lost.

  How to I ensure that ufw is fully up and initialised BEFORE the
  fail2ban service starts?

  -
  root@loki:~# ./ufw-diag.sh
  Has python: pass (binary: python3, version: 3.8.10, py3)
  Has iptables: pass
  Has ip6tables: pass

  Has /proc/net/dev: pass
  Has /proc/net/if_inet6: pass

  This script will now attempt to create various rules using the iptables
  and ip6tables commands. This may result in module autoloading (eg, for
  IPv6).
  Proceed with checks (Y/n)?
  == IPv4 ==
  Creating 'ufw-check-requirements'... done
  Inserting RETURN at top of 'ufw-check-requirements'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: pass
  LOG: pass
  hashlimit: pass
  limit: pass
  ctstate (NEW): pass
  ctstate (RELATED): pass
  ctstate (ESTABLISHED): pass
  ctstate (INVALID): pass
  ctstate (new, recent set): pass
  ctstate (new, recent update): pass
  ctstate (new, limit): pass
  interface (input): pass
  interface (output): pass
  multiport: pass
  comment: pass
  addrtype (LOCAL): pass
  addrtype (MULTICAST): pass
  addrtype (BROADCAST): pass
  icmp (destination-unreachable): pass
  icmp (source-quench): pass
  icmp (time-exceeded): pass
  icmp (parameter-problem): pass
  icmp (echo-request): pass

  == IPv6 ==
  Creating 'ufw-check-requirements6'... done
  Inserting RETURN at top of 'ufw-check-requirements6'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: pass
  LOG: pass
  hashlimit: pass
  limit: pass
  ctstate (NEW): pass
  ctstate (RELATED): pass
  ctstate (ESTABLISHED): pass
  ctstate (INVALID): pass
  ctstate (new, recent set): pass
  ctstate (new, recent update): pass
  ctstate (new, limit): pass
  interface (input): pass
  interface (output): pass
  multiport: pass
  comment: pass
  icmpv6 (destination-unreachable): pass
  icmpv6 (packet-too-big): pass
  icmpv6 (time-exceeded): pass
  icmpv6 (parameter-problem): pass
  icmpv6 (echo-request): pass
  icmpv6 with hl (neighbor-solicitation): pass
  icmpv6 with hl (neighbor-advertisement): pass
  icmpv6 with hl (router-solicitation): pass
  icmpv6 with hl (router-advertisement): pass
  ipv6 rt: pass

  All tests passed
  -
  root@loki:/lib/systemd/system# cat ufw.service
  [Unit]
  Description=Uncomplicated firewall
  Documentation=man:ufw(8)
  DefaultDependencies=no
  Before=network.target
  After=NetworkManager.service

  [Service]
  Type=oneshot
  RemainAfterExit=yes
  ExecStart=/lib/ufw/ufw-init start quiet
  # ExecStartPost=/bin/sleep 10
  ExecStop=/lib/ufw/ufw-init stop

  [Install]
  WantedBy=multi-user.target

  -
  root@loki:/lib/systemd/system# cat fail2ban.service
  [Unit]
  Description=Fail2Ban Service
  Documentation=man:fail2ban(1)
  After=network.target iptables.service firewalld.service ip6tables.service 
ipset.service nftables.service ufw.service
  PartOf=firewalld.service

  [Service]
  Type=simple
  ExecStartPre=/bin/mkdir -p /run/fail2ban
  ExecStart=/usr/bin/fail2ban-server -xf start
  # if should be logged in systemd journal, use following line or set logtarget 
to sysout in fail2ban.local
  # ExecStart=/usr/bin/fail2ban-server -xf --logtarget=sysout start
  ExecStop=/usr/bin/fail2ban-client stop
  ExecReload=/usr/bin/fail2ban-client reload
  PIDFile=/run/fail2ban/fail2ban.pid
  Restart=on-failure
  RestartPreventExitStatus=0 255

  [Install]
  WantedBy=multi-user.target

  -
  root@loki:/etc/default# cat ufw
  # /etc/default/ufw
  

[Touch-packages] [Bug 1956029] Re: ufw remains inactive at boot time

2021-12-30 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1956029

Title:
  ufw remains inactive at boot time

Status in ufw package in Ubuntu:
  Incomplete

Bug description:
  I was advised to start a bug report (Comment 38):
  https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856

  I "ufw enable" then several seconds later networking stops. I have get
  Ubuntu to gracefully power-down using the power-button and then
  gracefully power-up.

  Out of curiosity, is anyone here having this problem wish ufw starting
  up at boot time while also using having fail2ban installed?

  Here is my theory. It takes a while for fail2ban to issue all the
  iptable commands to configure the firewall. When ufw tries to
  initialise there may be a clash or lock held either by an iptables
  instance spawned by fail2ban or an iptables instance spawned by ufw.
  One of them will fail and will quite probably mess-up ufw's rules
  breaking network connectivity.

  This time I waited for fail2ban to finish establishing its iptables
  rules before issuing "ufw enable" and this time round network
  connectivity was not lost.

  How to I ensure that ufw is fully up and initialised BEFORE the
  fail2ban service starts?

  -
  root@loki:~# ./ufw-diag.sh
  Has python: pass (binary: python3, version: 3.8.10, py3)
  Has iptables: pass
  Has ip6tables: pass

  Has /proc/net/dev: pass
  Has /proc/net/if_inet6: pass

  This script will now attempt to create various rules using the iptables
  and ip6tables commands. This may result in module autoloading (eg, for
  IPv6).
  Proceed with checks (Y/n)?
  == IPv4 ==
  Creating 'ufw-check-requirements'... done
  Inserting RETURN at top of 'ufw-check-requirements'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: pass
  LOG: pass
  hashlimit: pass
  limit: pass
  ctstate (NEW): pass
  ctstate (RELATED): pass
  ctstate (ESTABLISHED): pass
  ctstate (INVALID): pass
  ctstate (new, recent set): pass
  ctstate (new, recent update): pass
  ctstate (new, limit): pass
  interface (input): pass
  interface (output): pass
  multiport: pass
  comment: pass
  addrtype (LOCAL): pass
  addrtype (MULTICAST): pass
  addrtype (BROADCAST): pass
  icmp (destination-unreachable): pass
  icmp (source-quench): pass
  icmp (time-exceeded): pass
  icmp (parameter-problem): pass
  icmp (echo-request): pass

  == IPv6 ==
  Creating 'ufw-check-requirements6'... done
  Inserting RETURN at top of 'ufw-check-requirements6'... done
  TCP: pass
  UDP: pass
  destination port: pass
  source port: pass
  ACCEPT: pass
  DROP: pass
  REJECT: 

[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network

2021-12-29 Thread Jamie Strandboge
** 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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1950039

Title:
  ufw 0.36.1-3 introduces ordering cycle, breaking network

Status in ufw package in Ubuntu:
  New

Bug description:

   [2.065178] systemd[1]: 
systemd-networkd.service: Found ordering cycle on network-pre.target/start

   [2.065276] systemd[1]: 
systemd-networkd.service: Found dependency on ufw.service/start

   [2.065356] systemd[1]: 
systemd-networkd.service: Found dependency on basic.target/start

   [2.065422] systemd[1]: 
systemd-networkd.service: Found dependency on sockets.target/start

   [2.065487] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star
  t

   [2.065561] systemd[1]: 
systemd-networkd.service: Found dependency on sysinit.target/start

   [2.065626] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init.service/start

   [2.065700] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se
  rvice/start

   [2.065795] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd.service/start

   [2.065870] systemd[1]: 
systemd-networkd.service: Job network-pre.target/start deleted to break 
ordering cycle starting with systemd-networkd.service/start

   [[0;1;31m SKIP [0m] Ordering cycle found, 
skipping [0;1;39mNetwork (Pre)[0m

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network

2021-12-29 Thread Jamie Strandboge
** 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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1950039

Title:
  ufw 0.36.1-3 introduces ordering cycle, breaking network

Status in ufw package in Ubuntu:
  New

Bug description:

   [2.065178] systemd[1]: 
systemd-networkd.service: Found ordering cycle on network-pre.target/start

   [2.065276] systemd[1]: 
systemd-networkd.service: Found dependency on ufw.service/start

   [2.065356] systemd[1]: 
systemd-networkd.service: Found dependency on basic.target/start

   [2.065422] systemd[1]: 
systemd-networkd.service: Found dependency on sockets.target/start

   [2.065487] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star
  t

   [2.065561] systemd[1]: 
systemd-networkd.service: Found dependency on sysinit.target/start

   [2.065626] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init.service/start

   [2.065700] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se
  rvice/start

   [2.065795] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd.service/start

   [2.065870] systemd[1]: 
systemd-networkd.service: Job network-pre.target/start deleted to break 
ordering cycle starting with systemd-networkd.service/start

   [[0;1;31m SKIP [0m] Ordering cycle found, 
skipping [0;1;39mNetwork (Pre)[0m

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network

2021-12-29 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1950039

Title:
  ufw 0.36.1-3 introduces ordering cycle, breaking network

Status in ufw package in Ubuntu:
  New

Bug description:

   [2.065178] systemd[1]: 
systemd-networkd.service: Found ordering cycle on network-pre.target/start

   [2.065276] systemd[1]: 
systemd-networkd.service: Found dependency on ufw.service/start

   [2.065356] systemd[1]: 
systemd-networkd.service: Found dependency on basic.target/start

   [2.065422] systemd[1]: 
systemd-networkd.service: Found dependency on sockets.target/start

   [2.065487] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star
  t

   [2.065561] systemd[1]: 
systemd-networkd.service: Found dependency on sysinit.target/start

   [2.065626] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init.service/start

   [2.065700] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se
  rvice/start

   [2.065795] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd.service/start

   [2.065870] systemd[1]: 
systemd-networkd.service: Job network-pre.target/start deleted to break 
ordering cycle starting with systemd-networkd.service/start

   [[0;1;31m SKIP [0m] Ordering cycle found, 
skipping [0;1;39mNetwork (Pre)[0m

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network

2021-12-29 Thread Jamie Strandboge
@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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1950039

Title:
  ufw 0.36.1-3 introduces ordering cycle, breaking network

Status in ufw package in Ubuntu:
  New

Bug description:
  

[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network

2021-12-29 Thread Jamie Strandboge
** Changed in: ufw (Ubuntu)
   Status: Triaged => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1950039

Title:
  ufw 0.36.1-3 introduces ordering cycle, breaking network

Status in ufw package in Ubuntu:
  Incomplete

Bug description:

   [2.065178] systemd[1]: 
systemd-networkd.service: Found ordering cycle on network-pre.target/start

   [2.065276] systemd[1]: 
systemd-networkd.service: Found dependency on ufw.service/start

   [2.065356] systemd[1]: 
systemd-networkd.service: Found dependency on basic.target/start

   [2.065422] systemd[1]: 
systemd-networkd.service: Found dependency on sockets.target/start

   [2.065487] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star
  t

   [2.065561] systemd[1]: 
systemd-networkd.service: Found dependency on sysinit.target/start

   [2.065626] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init.service/start

   [2.065700] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se
  rvice/start

   [2.065795] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd.service/start

   [2.065870] systemd[1]: 
systemd-networkd.service: Job network-pre.target/start deleted to break 
ordering cycle starting with systemd-networkd.service/start

   [[0;1;31m SKIP [0m] Ordering cycle found, 
skipping [0;1;39mNetwork (Pre)[0m

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network

2021-12-29 Thread Jamie Strandboge
@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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1950039

Title:
  ufw 0.36.1-3 introduces ordering cycle, breaking network

Status in ufw package in Ubuntu:
  Triaged

Bug description:

   [2.065178] systemd[1]: 
systemd-networkd.service: Found ordering cycle on network-pre.target/start

   [2.065276] systemd[1]: 
systemd-networkd.service: Found dependency on ufw.service/start

   [2.065356] systemd[1]: 
systemd-networkd.service: Found dependency on basic.target/start

   [2.065422] systemd[1]: 
systemd-networkd.service: Found dependency on sockets.target/start

   [2.065487] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star
  t

   [2.065561] systemd[1]: 
systemd-networkd.service: Found dependency on sysinit.target/start

   [2.065626] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init.service/start

   [2.065700] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se
  rvice/start

   [2.065795] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd.service/start

   [2.065870] systemd[1]: 
systemd-networkd.service: Job network-pre.target/start deleted to break 
ordering cycle starting with systemd-networkd.service/start

   [[0;1;31m SKIP [0m] Ordering cycle found, 
skipping [0;1;39mNetwork (Pre)[0m

To manage notifications about this 

[Touch-packages] [Bug 1726856] Re: ufw does not start automatically at boot

2021-12-29 Thread Jamie Strandboge
@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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1726856

Title:
  ufw does not start automatically at boot

Status in ufw:
  Invalid
Status in ufw package in Ubuntu:
  Fix Released
Status in ufw source package in Xenial:
  Invalid
Status in ufw source package in Bionic:
  Invalid
Status in ufw source package in Cosmic:
  Invalid
Status in ufw source package in Disco:
  Invalid

Bug description:
  Whenever I boot into 17.10 ufw is always inactive, even though
  /etc/ufw/ufw.conf has this:

  # Set to yes to start on boot. If setting this remotely, be sure to add a rule
  # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp'
  ENABLED=yes

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ufw 0.35-5
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 24 13:56:40 2017
  InstallationDate: Installed on 2015-04-01 (936 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.2)
  PackageArchitecture: all
  SourcePackage: ufw
  UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago)
  mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170

To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/1726856/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1951018] Re: No ability to discern IPv4 vs IPv6 rules through Python

2021-11-17 Thread Jamie Strandboge
** Also affects: ufw
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1951018

Title:
  No ability to discern IPv4 vs IPv6 rules through Python

Status in ufw:
  New
Status in ufw package in Ubuntu:
  New

Bug description:
  Version: ufw 0.36
  Ubuntu Version: 20.04.3 LTS

  There doesn't appear to be a Python method for accessing IPv4 and IPv6
  rules in a distinguishable manner.

  In the source code (root/src/backend.py) there is an object that
  stores IPv4 and IPv6 rules in separate lists. Those lists are then
  accessed with the following method:

  def get_rules(self):
  '''Return list of all rules'''
  return self.rules + self.rules6

  The issue with this is that the returned list doesn't contain an
  indication of what IP version each item corresponds to and would
  display something like the following.

  1 allow 22/tcp
  2 allow 80
  3 allow 443
  4 allow 22/tcp
  5 allow 80
  6 allow 443

  I don't currently see a way to distinguish between IPv4 and IPv6 rules other 
than accessing the lists in the backend object directly (but I don't think this 
is best practice). E.g.:
  rules_ipv4 = backend.rules
  rules_ipv6 = backend.rules6

  One possible fix would be to add functions that return only the IPv4 or IPv6 
rules. E.g.:
  def get_rules_ipv4(self):
  '''Return list of all ipv4 rules'''
  return self.rules
  def get_rules_ipv6(self):
  '''Return list of all ipv6 rules'''
  return self.rules6

To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/1951018/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network

2021-11-06 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1950039

Title:
  ufw 0.36.1-3 introduces ordering cycle, breaking network

Status in ufw package in Ubuntu:
  Triaged

Bug description:

   [2.065178] systemd[1]: 
systemd-networkd.service: Found ordering cycle on network-pre.target/start

   [2.065276] systemd[1]: 
systemd-networkd.service: Found dependency on ufw.service/start

   [2.065356] systemd[1]: 
systemd-networkd.service: Found dependency on basic.target/start

   [2.065422] systemd[1]: 
systemd-networkd.service: Found dependency on sockets.target/start

   [2.065487] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star
  t

   [2.065561] systemd[1]: 
systemd-networkd.service: Found dependency on sysinit.target/start

   [2.065626] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init.service/start

   [2.065700] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se
  rvice/start

   [2.065795] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd.service/start

   [2.065870] systemd[1]: 
systemd-networkd.service: Job network-pre.target/start deleted to break 
ordering cycle starting with systemd-networkd.service/start

   [[0;1;31m SKIP [0m] Ordering cycle found, 
skipping [0;1;39mNetwork (Pre)[0m

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network

2021-11-06 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1950039

Title:
  ufw 0.36.1-3 introduces ordering cycle, breaking network

Status in ufw package in Ubuntu:
  Triaged

Bug description:

   [2.065178] systemd[1]: 
systemd-networkd.service: Found ordering cycle on network-pre.target/start

   [2.065276] systemd[1]: 
systemd-networkd.service: Found dependency on ufw.service/start

   [2.065356] systemd[1]: 
systemd-networkd.service: Found dependency on basic.target/start

   [2.065422] systemd[1]: 
systemd-networkd.service: Found dependency on sockets.target/start

   [2.065487] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star
  t

   [2.065561] systemd[1]: 
systemd-networkd.service: Found dependency on sysinit.target/start

   [2.065626] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init.service/start

   [2.065700] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se
  rvice/start

   [2.065795] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd.service/start

   [2.065870] systemd[1]: 
systemd-networkd.service: Job network-pre.target/start deleted to break 
ordering cycle starting with systemd-networkd.service/start

   [[0;1;31m SKIP [0m] Ordering cycle found, 
skipping [0;1;39mNetwork (Pre)[0m

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network

2021-11-06 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1950039

Title:
  ufw 0.36.1-3 introduces ordering cycle, breaking network

Status in ufw package in Ubuntu:
  Triaged

Bug description:

   [2.065178] systemd[1]: 
systemd-networkd.service: Found ordering cycle on network-pre.target/start

   [2.065276] systemd[1]: 
systemd-networkd.service: Found dependency on ufw.service/start

   [2.065356] systemd[1]: 
systemd-networkd.service: Found dependency on basic.target/start

   [2.065422] systemd[1]: 
systemd-networkd.service: Found dependency on sockets.target/start

   [2.065487] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star
  t

   [2.065561] systemd[1]: 
systemd-networkd.service: Found dependency on sysinit.target/start

   [2.065626] systemd[1]: 
systemd-networkd.service: Found dependency on cloud-init.service/start

   [2.065700] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se
  rvice/start

   [2.065795] systemd[1]: 
systemd-networkd.service: Found dependency on systemd-networkd.service/start

   [2.065870] systemd[1]: 
systemd-networkd.service: Job network-pre.target/start deleted to break 
ordering cycle starting with systemd-networkd.service/start

   [[0;1;31m SKIP [0m] Ordering cycle found, 
skipping [0;1;39mNetwork (Pre)[0m

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1946804] Re: ufw breaks boot on network root filesystem

2021-11-03 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1946804

Title:
  ufw breaks boot on network root filesystem

Status in ufw:
  Fix Committed
Status in ufw package in Ubuntu:
  Fix Released
Status in ufw source package in Bionic:
  Fix Committed
Status in ufw source package in Focal:
  Fix Committed
Status in ufw source package in Hirsute:
  Fix Committed
Status in ufw source package in Impish:
  Fix Committed

Bug description:
  [Impact]

  A system with rootfs on iSCSI stops booting when ufw.service starts.
  The kernel logs iSCSI command/reset timeout until I/O fails and the
  root filesystem/journal break.

  The issue is that ufw_start() sets the default policy _first_, then
  adds rules _later_.

  So, a default INPUT policy of DROP (default setting in ufw) prevents
  further access to the root filesystem (blocks incoming iSCSI traffic)
  thus any rules that could help are not loaded (nor anything else.)

  [Fix]

  The fix is to set default policy after loading rules in ufw_start().
  That seems to be OK as `ip[6]tables-restore -n/--noflush` is used,
  and per iptables source, that only sets the chain policy.

  This allows the system to boot due to the RELATED,ESTABLISHED rule,
  that is introduced by before.rules in INPUT/ufw-before-input chain.

  The comparison of `iptables -L` before/after shows no differences
  (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors.

  [Test Steps]

   * Install Ubuntu on an iSCSI (or other network-based) root filesystem.
     (eg, Oracle Cloud's bare-metal 'BM.Standard1.36' shape.)

   * sudo ufw enable

   * Observed: system may stall immediately if no prior iptables rules.
     (eg, iptables -A INPUT -p tcp -s 169.254.0.2 --sport 3260 -j ACCEPT)

   * Expected: system continues working.

   * sudo reboot

   * Observed: system boot stalls once ufw.service starts (see below.)
   * Expected: system boot should move on.

  [Regression Potential]

   * Potential regressions would be observed on ufw start/reload,
     when iptables rules are configured.

   * The resulting iptables configuration has been compared
     before/after the change, with identical rules on both.

  [Other Info]

   * Fixed in Debian and Jammy.

  [ufw info]

  # ufw --version
  ufw 0.36
  Copyright 2008-2015 Canonical Ltd.

  # lsb_release -cs
  focal

  [Boot Log]

  [ 232.168355] iBFT detected.
  Begin: Running /scripts/init-premount ... done.
  Begin: Mounting root file system ... Begin: Running /scripts/local-top ...
  Setting up software interface enp45s0f0np0
  ...
  [ 254.644505] Loading iSCSI transport class v2.0-870.
  [ 254.714938] iscsi: registered transport (tcp)
  [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP
  ...
  [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 
GB/120 GiB)
  ...
  [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. 
Opts: (null)
  ...
  [ 266.620860] systemd[1]: Starting Uncomplicated firewall...
  Starting Uncomplicated firewall...
  ...
  [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 
timedout
  [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh
  [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 
timedout
  [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh
  [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696
  [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13]
  [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout
  [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 
timedout
  [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh
  [ 314.107541] session1: iscsi_tmf_timedout tmf timedout
  [ 314.169797] connection1:0: detected conn error (1021)
  [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 
0x13]
  [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246
  [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it 
completed.
  [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5
  [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it 
completed.
  [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 
lun 1]
  [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED
  [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 
tgt <...>]
  [ 314.954144] session1: iscsi_eh_target_reset tgt 

[Touch-packages] [Bug 1946804] Re: ufw breaks boot on network root filesystem

2021-11-03 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1946804

Title:
  ufw breaks boot on network root filesystem

Status in ufw:
  Fix Committed
Status in ufw package in Ubuntu:
  Fix Released
Status in ufw source package in Bionic:
  Fix Committed
Status in ufw source package in Focal:
  Fix Committed
Status in ufw source package in Hirsute:
  Fix Committed
Status in ufw source package in Impish:
  Fix Committed

Bug description:
  [Impact]

  A system with rootfs on iSCSI stops booting when ufw.service starts.
  The kernel logs iSCSI command/reset timeout until I/O fails and the
  root filesystem/journal break.

  The issue is that ufw_start() sets the default policy _first_, then
  adds rules _later_.

  So, a default INPUT policy of DROP (default setting in ufw) prevents
  further access to the root filesystem (blocks incoming iSCSI traffic)
  thus any rules that could help are not loaded (nor anything else.)

  [Fix]

  The fix is to set default policy after loading rules in ufw_start().
  That seems to be OK as `ip[6]tables-restore -n/--noflush` is used,
  and per iptables source, that only sets the chain policy.

  This allows the system to boot due to the RELATED,ESTABLISHED rule,
  that is introduced by before.rules in INPUT/ufw-before-input chain.

  The comparison of `iptables -L` before/after shows no differences
  (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors.

  [Test Steps]

   * Install Ubuntu on an iSCSI (or other network-based) root filesystem.
     (eg, Oracle Cloud's bare-metal 'BM.Standard1.36' shape.)

   * sudo ufw enable

   * Observed: system may stall immediately if no prior iptables rules.
     (eg, iptables -A INPUT -p tcp -s 169.254.0.2 --sport 3260 -j ACCEPT)

   * Expected: system continues working.

   * sudo reboot

   * Observed: system boot stalls once ufw.service starts (see below.)
   * Expected: system boot should move on.

  [Regression Potential]

   * Potential regressions would be observed on ufw start/reload,
     when iptables rules are configured.

   * The resulting iptables configuration has been compared
     before/after the change, with identical rules on both.

  [Other Info]

   * Fixed in Debian and Jammy.

  [ufw info]

  # ufw --version
  ufw 0.36
  Copyright 2008-2015 Canonical Ltd.

  # lsb_release -cs
  focal

  [Boot Log]

  [ 232.168355] iBFT detected.
  Begin: Running /scripts/init-premount ... done.
  Begin: Mounting root file system ... Begin: Running /scripts/local-top ...
  Setting up software interface enp45s0f0np0
  ...
  [ 254.644505] Loading iSCSI transport class v2.0-870.
  [ 254.714938] iscsi: registered transport (tcp)
  [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP
  ...
  [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 
GB/120 GiB)
  ...
  [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. 
Opts: (null)
  ...
  [ 266.620860] systemd[1]: Starting Uncomplicated firewall...
  Starting Uncomplicated firewall...
  ...
  [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 
timedout
  [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh
  [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 
timedout
  [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh
  [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696
  [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13]
  [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout
  [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 
timedout
  [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh
  [ 314.107541] session1: iscsi_tmf_timedout tmf timedout
  [ 314.169797] connection1:0: detected conn error (1021)
  [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 
0x13]
  [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246
  [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it 
completed.
  [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5
  [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it 
completed.
  [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 
lun 1]
  [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED
  [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 
tgt <...>]
  [ 314.954144] session1: iscsi_eh_target_reset tgt <...> reset 

[Touch-packages] [Bug 1933117] Re: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule

2021-11-03 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1933117

Title:
  ufw delete can confuse protocol-specific rule with otherwise matching
  'proto any' rule

Status in ufw:
  Fix Released
Status in ufw package in Ubuntu:
  Fix Released
Status in ufw source package in Bionic:
  Fix Committed
Status in ufw source package in Focal:
  Fix Committed
Status in ufw source package in Hirsute:
  Fix Committed

Bug description:
  [Impact]

   * The deletion of a rule without the 'proto' field
 that has a similar rule *with* the 'proto' field
 might delete the wrong rule (the latter).
 
   * This might cause services to be inaccessible or
 incorrectly allowed, depending on rule ordering
 (read original description below for examples.)

  [Test Steps]

   * Add rules:
 ufw allow from 1.1.1.1 port  proto tcp
 ufw allow from 2.2.2.2 port  proto tcp
 ufw allow from 1.1.1.1 port 

   * Check iptables:
 iptables -L ufw-user-input -n
 ...
 ACCEPT tcp  --  1.1.1.1   0.0.0.0/0   tcp spt:
 ACCEPT tcp  --  2.2.2.2   0.0.0.0/0   tcp spt:
 ACCEPT tcp  --  1.1.1.1   0.0.0.0/0   tcp spt:
 ACCEPT udp  --  1.1.1.1   0.0.0.0/0   udp spt:

   * Delete the third rule above
 ufw status numbered
 yes | ufw delete 3
   
   * Check iptables again:
 iptables -L ufw-user-input -n 

 Observed: (deleted tcp line from first rule, and udp line from third rule)
 ...
 ACCEPT tcp  --  2.2.2.2   0.0.0.0/0   tcp spt:
 ACCEPT tcp  --  1.1.1.1   0.0.0.0/0   tcp spt:
 
 Expected: (deleted both tcp and udp lines from third rule)
 ...  
 ACCEPT tcp  --  1.1.1.1   0.0.0.0/0   tcp spt:
 ACCEPT tcp  --  2.2.2.2   0.0.0.0/0   tcp spt:

  [Regression Potential]

   * Potential regressions would be observed when deleting rules.
   
   * This fix has been suggested for SRU by jdstrand [1], 
 and has already been available in 21.04 and the snap.
   
   [1] 
https://code.launchpad.net/~mfo/ufw/+git/ufw/+merge/410091/comments/1083005

  [Original Description]

  UFW versions 0.35 (on Ubuntu 16.04 LTS) and 0.36 (on Ubuntu 20.04 LTS)

  If a rule is inserted without specifying the protocol, it will default
  to both udp and tcp. If a second rule is inserted earlier in the order
  that specifies the protocol but is otherwise identical, UFW will
  delete the wrong rule if the first rule is deleted.

  This is repeatable with the following script:

  ufw insert 1 allow from 1.1.1.1/26 to any port 22
  ufw insert 2 allow from 1.2.3.4/26 to any port 22
  ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp
  iptables -L -n | grep -A 6 "Chain ufw-user-input"
  yes | ufw delete 3
  iptables -L -n | grep -A 4 "Chain ufw-user-input"

  The output is as follows:

  Chain ufw-user-input (1 references)
  target prot opt source   destination
  ACCEPT tcp  --  1.2.3.0/26   0.0.0.0/0tcp dpt:22
  ACCEPT tcp  --  1.1.1.0/26   0.0.0.0/0tcp dpt:22
  ACCEPT udp  --  1.1.1.0/26   0.0.0.0/0udp dpt:22
  ACCEPT tcp  --  1.2.3.0/26   0.0.0.0/0tcp dpt:22
  ACCEPT udp  --  1.2.3.0/26   0.0.0.0/0udp dpt:22

  Chain ufw-user-input (1 references)
  target prot opt source   destination
  ACCEPT tcp  --  1.1.1.0/26   0.0.0.0/0tcp dpt:22
  ACCEPT udp  --  1.1.1.0/26   0.0.0.0/0udp dpt:22
  ACCEPT tcp  --  1.2.3.0/26   0.0.0.0/0tcp dpt:22

  UFW deleted the first rule for 1.2.3.0 and then the last rule for
  1.2.3.0, leaving the wrong rule remaining. Here is the ufw status:

  To Action  From
  -- --  
  22/tcp ALLOW   1.2.3.0/26
  22 ALLOW   1.1.1.0/26

  Mixing ALLOW and REJECT/DENY rules can further result in incorrect
  behavior due to this incorrect reordering. On port 22, this could
  render SSH remotely inaccessible.

  For example, if one had initially set up the following rule to port 22
  (TCP and UDP)...

  ufw insert 1 allow from 1.2.3.4 to any port 22

  ...and later wanted to further restrict it to only TCP, while
  explicitly rejecting any other port 22 connections...

  ufw insert 1 allow from 1.2.3.4 to any port 22 proto tcp
  ufw insert 2 reject from any to any port 22
  yes | ufw delete 3

  ...this would result in SSH becoming inaccessible.

  

[Touch-packages] [Bug 1933117] Re: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule

2021-11-03 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1933117

Title:
  ufw delete can confuse protocol-specific rule with otherwise matching
  'proto any' rule

Status in ufw:
  Fix Released
Status in ufw package in Ubuntu:
  Fix Released
Status in ufw source package in Bionic:
  Fix Committed
Status in ufw source package in Focal:
  Fix Committed
Status in ufw source package in Hirsute:
  Fix Committed

Bug description:
  [Impact]

   * The deletion of a rule without the 'proto' field
 that has a similar rule *with* the 'proto' field
 might delete the wrong rule (the latter).
 
   * This might cause services to be inaccessible or
 incorrectly allowed, depending on rule ordering
 (read original description below for examples.)

  [Test Steps]

   * Add rules:
 ufw allow from 1.1.1.1 port  proto tcp
 ufw allow from 2.2.2.2 port  proto tcp
 ufw allow from 1.1.1.1 port 

   * Check iptables:
 iptables -L ufw-user-input -n
 ...
 ACCEPT tcp  --  1.1.1.1   0.0.0.0/0   tcp spt:
 ACCEPT tcp  --  2.2.2.2   0.0.0.0/0   tcp spt:
 ACCEPT tcp  --  1.1.1.1   0.0.0.0/0   tcp spt:
 ACCEPT udp  --  1.1.1.1   0.0.0.0/0   udp spt:

   * Delete the third rule above
 ufw status numbered
 yes | ufw delete 3
   
   * Check iptables again:
 iptables -L ufw-user-input -n 

 Observed: (deleted tcp line from first rule, and udp line from third rule)
 ...
 ACCEPT tcp  --  2.2.2.2   0.0.0.0/0   tcp spt:
 ACCEPT tcp  --  1.1.1.1   0.0.0.0/0   tcp spt:
 
 Expected: (deleted both tcp and udp lines from third rule)
 ...  
 ACCEPT tcp  --  1.1.1.1   0.0.0.0/0   tcp spt:
 ACCEPT tcp  --  2.2.2.2   0.0.0.0/0   tcp spt:

  [Regression Potential]

   * Potential regressions would be observed when deleting rules.
   
   * This fix has been suggested for SRU by jdstrand [1], 
 and has already been available in 21.04 and the snap.
   
   [1] 
https://code.launchpad.net/~mfo/ufw/+git/ufw/+merge/410091/comments/1083005

  [Original Description]

  UFW versions 0.35 (on Ubuntu 16.04 LTS) and 0.36 (on Ubuntu 20.04 LTS)

  If a rule is inserted without specifying the protocol, it will default
  to both udp and tcp. If a second rule is inserted earlier in the order
  that specifies the protocol but is otherwise identical, UFW will
  delete the wrong rule if the first rule is deleted.

  This is repeatable with the following script:

  ufw insert 1 allow from 1.1.1.1/26 to any port 22
  ufw insert 2 allow from 1.2.3.4/26 to any port 22
  ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp
  iptables -L -n | grep -A 6 "Chain ufw-user-input"
  yes | ufw delete 3
  iptables -L -n | grep -A 4 "Chain ufw-user-input"

  The output is as follows:

  Chain ufw-user-input (1 references)
  target prot opt source   destination
  ACCEPT tcp  --  1.2.3.0/26   0.0.0.0/0tcp dpt:22
  ACCEPT tcp  --  1.1.1.0/26   0.0.0.0/0tcp dpt:22
  ACCEPT udp  --  1.1.1.0/26   0.0.0.0/0udp dpt:22
  ACCEPT tcp  --  1.2.3.0/26   0.0.0.0/0tcp dpt:22
  ACCEPT udp  --  1.2.3.0/26   0.0.0.0/0udp dpt:22

  Chain ufw-user-input (1 references)
  target prot opt source   destination
  ACCEPT tcp  --  1.1.1.0/26   0.0.0.0/0tcp dpt:22
  ACCEPT udp  --  1.1.1.0/26   0.0.0.0/0udp dpt:22
  ACCEPT tcp  --  1.2.3.0/26   0.0.0.0/0tcp dpt:22

  UFW deleted the first rule for 1.2.3.0 and then the last rule for
  1.2.3.0, leaving the wrong rule remaining. Here is the ufw status:

  To Action  From
  -- --  
  22/tcp ALLOW   1.2.3.0/26
  22 ALLOW   1.1.1.0/26

  Mixing ALLOW and REJECT/DENY rules can further result in incorrect
  behavior due to this incorrect reordering. On port 22, this could
  render SSH remotely inaccessible.

  For example, if one had initially set up the following rule to port 22
  (TCP and UDP)...

  ufw insert 1 allow from 1.2.3.4 to any port 22

  ...and later wanted to further restrict it to only TCP, while
  explicitly rejecting any other port 22 connections...

  ufw insert 1 allow from 1.2.3.4 to any port 22 proto tcp
  ufw insert 2 reject from any to any port 22
  yes | ufw delete 3

  ...this would result in SSH becoming inaccessible.

  Instead if one had the initial configuration...

  ufw 

[Touch-packages] [Bug 1726856] Re: ufw does not start automatically at boot

2021-11-02 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1726856

Title:
  ufw does not start automatically at boot

Status in ufw:
  Invalid
Status in ufw package in Ubuntu:
  Invalid
Status in ufw source package in Xenial:
  Invalid
Status in ufw source package in Bionic:
  Invalid
Status in ufw source package in Cosmic:
  Invalid
Status in ufw source package in Disco:
  Invalid

Bug description:
  Whenever I boot into 17.10 ufw is always inactive, even though
  /etc/ufw/ufw.conf has this:

  # Set to yes to start on boot. If setting this remotely, be sure to add a rule
  # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp'
  ENABLED=yes

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ufw 0.35-5
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 24 13:56:40 2017
  InstallationDate: Installed on 2015-04-01 (936 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.2)
  PackageArchitecture: all
  SourcePackage: ufw
  UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago)
  mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170

To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/1726856/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1946804] Re: ufw breaks boot on network root filesystem

2021-10-13 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1946804

Title:
  ufw breaks boot on network root filesystem

Status in ufw:
  Fix Committed
Status in ufw package in Ubuntu:
  New
Status in ufw source package in Bionic:
  New
Status in ufw source package in Focal:
  New
Status in ufw source package in Hirsute:
  New
Status in ufw source package in Impish:
  New

Bug description:
  [Impact]

  A system with rootfs on iSCSI stops booting when ufw.service starts.
  The kernel logs iSCSI command/reset timeout until I/O fails and the
  root filesystem/journal break.

  The issue is that ufw_start() sets the default policy _first_, then
  adds rules _later_.

  So, a default INPUT policy of DROP (default setting in ufw) prevents
  further access to the root filesystem (blocks incoming iSCSI traffic)
  thus any rules that could help are not loaded (nor anything else.)

  [Fix]

  The fix is to set default policy after loading rules in ufw_start().
  That seems to be OK as `ip[6]tables-restore -n/--noflush` is used,
  and per iptables source, that only sets the chain policy.

  This allows the system to boot due to the RELATED,ESTABLISHED rule,
  that is introduced by before.rules in INPUT/ufw-before-input chain.

  The comparison of `iptables -L` before/after shows no differences
  (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors.

  
  
  Functional tests summary
  
  Attempted:   22 (3339 individual tests)
  Skipped: 0
  Errors:  0

  [ufw info]

  # ufw --version
  ufw 0.36
  Copyright 2008-2015 Canonical Ltd.

  # lsb_release -cs
  focal

  [Boot Log]

  [ 232.168355] iBFT detected.
  Begin: Running /scripts/init-premount ... done.
  Begin: Mounting root file system ... Begin: Running /scripts/local-top ...
  Setting up software interface enp45s0f0np0
  ...
  [ 254.644505] Loading iSCSI transport class v2.0-870.
  [ 254.714938] iscsi: registered transport (tcp)
  [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP
  ...
  [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 
GB/120 GiB)
  ...
  [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. 
Opts: (null)
  ...
  [ 266.620860] systemd[1]: Starting Uncomplicated firewall...
  Starting Uncomplicated firewall...
  ...
  [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 
timedout
  [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh
  [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 
timedout
  [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh
  [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696
  [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13]
  [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout
  [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 
timedout
  [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh
  [ 314.107541] session1: iscsi_tmf_timedout tmf timedout
  [ 314.169797] connection1:0: detected conn error (1021)
  [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 
0x13]
  [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246
  [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it 
completed.
  [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5
  [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it 
completed.
  [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 
lun 1]
  [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED
  [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 
tgt <...>]
  [ 314.954144] session1: iscsi_eh_target_reset tgt <...> reset result = FAILED
  [ 315.063456] connection1:0: detected conn error (1021)
  [ 315.125743] session1: iscsi_eh_session_reset wait for relogin
  [ 398.843556] INFO: task systemd:1 blocked for more than 120 seconds.
  ...
  [ 401.039006] INFO: task jbd2/sda1-8:2522 blocked for more than 123 seconds.
  ...
  [ 402.483917] INFO: task iptables-restor:2648 blocked for more than 124 
seconds.
  ...
  [ 435.707549] session1: session recovery timed out after 120 secs
  [ 435.780058] session1: iscsi_eh_session_reset failing session reset: Could 
not log back into <...> [age 0]
  [ 435.920710] sd 12:0:0:1: Device offlined - not ready after error recovery
  [ 436.003563] sd 12:0:0:1: [sda] tag#105 FAILED Result: 
hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK cmd_age=169s
  [ 436.015520] sd 12:0:0:1: rejecting I/O to offline device
  [ 436.134354] sd 

[Touch-packages] [Bug 1946804] Re: ufw breaks boot on network root filesystem

2021-10-13 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1946804

Title:
  ufw breaks boot on network root filesystem

Status in ufw:
  Fix Committed
Status in ufw package in Ubuntu:
  New
Status in ufw source package in Bionic:
  New
Status in ufw source package in Focal:
  New
Status in ufw source package in Hirsute:
  New
Status in ufw source package in Impish:
  New

Bug description:
  [Impact]

  A system with rootfs on iSCSI stops booting when ufw.service starts.
  The kernel logs iSCSI command/reset timeout until I/O fails and the
  root filesystem/journal break.

  The issue is that ufw_start() sets the default policy _first_, then
  adds rules _later_.

  So, a default INPUT policy of DROP (default setting in ufw) prevents
  further access to the root filesystem (blocks incoming iSCSI traffic)
  thus any rules that could help are not loaded (nor anything else.)

  [Fix]

  The fix is to set default policy after loading rules in ufw_start().
  That seems to be OK as `ip[6]tables-restore -n/--noflush` is used,
  and per iptables source, that only sets the chain policy.

  This allows the system to boot due to the RELATED,ESTABLISHED rule,
  that is introduced by before.rules in INPUT/ufw-before-input chain.

  The comparison of `iptables -L` before/after shows no differences
  (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors.

  
  
  Functional tests summary
  
  Attempted:   22 (3339 individual tests)
  Skipped: 0
  Errors:  0

  [ufw info]

  # ufw --version
  ufw 0.36
  Copyright 2008-2015 Canonical Ltd.

  # lsb_release -cs
  focal

  [Boot Log]

  [ 232.168355] iBFT detected.
  Begin: Running /scripts/init-premount ... done.
  Begin: Mounting root file system ... Begin: Running /scripts/local-top ...
  Setting up software interface enp45s0f0np0
  ...
  [ 254.644505] Loading iSCSI transport class v2.0-870.
  [ 254.714938] iscsi: registered transport (tcp)
  [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP
  ...
  [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 
GB/120 GiB)
  ...
  [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. 
Opts: (null)
  ...
  [ 266.620860] systemd[1]: Starting Uncomplicated firewall...
  Starting Uncomplicated firewall...
  ...
  [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 
timedout
  [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh
  [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 
timedout
  [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh
  [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696
  [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13]
  [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout
  [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 
timedout
  [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh
  [ 314.107541] session1: iscsi_tmf_timedout tmf timedout
  [ 314.169797] connection1:0: detected conn error (1021)
  [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 
0x13]
  [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246
  [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it 
completed.
  [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5
  [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it 
completed.
  [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 
lun 1]
  [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED
  [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 
tgt <...>]
  [ 314.954144] session1: iscsi_eh_target_reset tgt <...> reset result = FAILED
  [ 315.063456] connection1:0: detected conn error (1021)
  [ 315.125743] session1: iscsi_eh_session_reset wait for relogin
  [ 398.843556] INFO: task systemd:1 blocked for more than 120 seconds.
  ...
  [ 401.039006] INFO: task jbd2/sda1-8:2522 blocked for more than 123 seconds.
  ...
  [ 402.483917] INFO: task iptables-restor:2648 blocked for more than 124 
seconds.
  ...
  [ 435.707549] session1: session recovery timed out after 120 secs
  [ 435.780058] session1: iscsi_eh_session_reset failing session reset: Could 
not log back into <...> [age 0]
  [ 435.920710] sd 12:0:0:1: Device offlined - not ready after error recovery
  [ 436.003563] sd 12:0:0:1: [sda] tag#105 FAILED Result: 
hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK cmd_age=169s
  [ 436.015520] sd 12:0:0:1: rejecting I/O to offline device
  [ 436.134354] sd 12:0:0:1: [sda] tag#105 CDB: Read(10) 28 00 00 05 8d d8 00 
00 08 00
  [ 

[Touch-packages] [Bug 1946804] Re: ufw breaks boot on network root filesystem

2021-10-13 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1946804

Title:
  ufw breaks boot on network root filesystem

Status in ufw:
  Fix Committed
Status in ufw package in Ubuntu:
  New
Status in ufw source package in Bionic:
  New
Status in ufw source package in Focal:
  New
Status in ufw source package in Hirsute:
  New
Status in ufw source package in Impish:
  New

Bug description:
  [Impact]

  A system with rootfs on iSCSI stops booting when ufw.service starts.
  The kernel logs iSCSI command/reset timeout until I/O fails and the
  root filesystem/journal break.

  The issue is that ufw_start() sets the default policy _first_, then
  adds rules _later_.

  So, a default INPUT policy of DROP (default setting in ufw) prevents
  further access to the root filesystem (blocks incoming iSCSI traffic)
  thus any rules that could help are not loaded (nor anything else.)

  [Fix]

  The fix is to set default policy after loading rules in ufw_start().
  That seems to be OK as `ip[6]tables-restore -n/--noflush` is used,
  and per iptables source, that only sets the chain policy.

  This allows the system to boot due to the RELATED,ESTABLISHED rule,
  that is introduced by before.rules in INPUT/ufw-before-input chain.

  The comparison of `iptables -L` before/after shows no differences
  (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors.

  
  
  Functional tests summary
  
  Attempted:   22 (3339 individual tests)
  Skipped: 0
  Errors:  0

  [ufw info]

  # ufw --version
  ufw 0.36
  Copyright 2008-2015 Canonical Ltd.

  # lsb_release -cs
  focal

  [Boot Log]

  [ 232.168355] iBFT detected.
  Begin: Running /scripts/init-premount ... done.
  Begin: Mounting root file system ... Begin: Running /scripts/local-top ...
  Setting up software interface enp45s0f0np0
  ...
  [ 254.644505] Loading iSCSI transport class v2.0-870.
  [ 254.714938] iscsi: registered transport (tcp)
  [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP
  ...
  [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 
GB/120 GiB)
  ...
  [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. 
Opts: (null)
  ...
  [ 266.620860] systemd[1]: Starting Uncomplicated firewall...
  Starting Uncomplicated firewall...
  ...
  [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 
timedout
  [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh
  [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 
timedout
  [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh
  [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696
  [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13]
  [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout
  [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 
timedout
  [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh
  [ 314.107541] session1: iscsi_tmf_timedout tmf timedout
  [ 314.169797] connection1:0: detected conn error (1021)
  [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 
0x13]
  [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246
  [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it 
completed.
  [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5
  [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it 
completed.
  [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 
lun 1]
  [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED
  [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 
tgt <...>]
  [ 314.954144] session1: iscsi_eh_target_reset tgt <...> reset result = FAILED
  [ 315.063456] connection1:0: detected conn error (1021)
  [ 315.125743] session1: iscsi_eh_session_reset wait for relogin
  [ 398.843556] INFO: task systemd:1 blocked for more than 120 seconds.
  ...
  [ 401.039006] INFO: task jbd2/sda1-8:2522 blocked for more than 123 seconds.
  ...
  [ 402.483917] INFO: task iptables-restor:2648 blocked for more than 124 
seconds.
  ...
  [ 435.707549] session1: session recovery timed out after 120 secs
  [ 435.780058] session1: iscsi_eh_session_reset failing session reset: Could 
not log back into <...> [age 0]
  [ 435.920710] sd 12:0:0:1: Device offlined - not ready after error recovery
  [ 436.003563] sd 12:0:0:1: [sda] tag#105 FAILED Result: 
hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK cmd_age=169s
  [ 436.015520] sd 12:0:0:1: rejecting I/O to offline device
  [ 436.134354] sd 12:0:0:1: [sda] tag#105 CDB: Read(10) 28 00 00 05 

[Touch-packages] [Bug 1794064] Re: Clicking a hyperlink in a PDF fails to open it if the default browser is a snap

2021-10-07 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to apparmor in 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

Status in apparmor package in Ubuntu:
  Confirmed
Status in evince package in Ubuntu:
  Triaged

Bug description:
  This is related to bug #1792648. After fixing that one (see discussion
  at https://salsa.debian.org/gnome-team/evince/merge_requests/1),
  clicking a hyperlink in a PDF opens it correctly if the default
  browser is a well-known application (such as /usr/bin/firefox), but it
  fails to do so if the default browser is a snap (e.g. the chromium
  snap).

  This is not a recent regression, it's not working on bionic either.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: evince 3.30.0-2
  ProcVersionSignature: Ubuntu 4.18.0-7.8-generic 4.18.5
  Uname: Linux 4.18.0-7-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu11
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Sep 24 12:28:06 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2016-07-02 (813 days ago)
  InstallationMedia: Ubuntu 16.04 LTS 

[Touch-packages] [Bug 1794064] Re: Clicking a hyperlink in a PDF fails to open it if the default browser is a snap

2021-10-07 Thread Jamie Strandboge
** Changed in: evince (Ubuntu)
 Assignee: Jamie Strandboge (jdstrand) => (unassigned)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in 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

Status in apparmor package in Ubuntu:
  Confirmed
Status in evince package in Ubuntu:
  Triaged

Bug description:
  This is related to bug #1792648. After fixing that one (see discussion
  at https://salsa.debian.org/gnome-team/evince/merge_requests/1),
  clicking a hyperlink in a PDF opens it correctly if the default
  browser is a well-known application (such as /usr/bin/firefox), but it
  fails to do so if the default browser is a snap (e.g. the chromium
  snap).

  This is not a recent regression, it's not working on bionic either.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: evince 3.30.0-2
  ProcVersionSignature: Ubuntu 4.18.0-7.8-generic 4.18.5
  Uname: Linux 4.18.0-7-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu11
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Sep 24 12:28:06 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2016-07-02 (813 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  SourcePackage: evince
  UpgradeStatus: Upgraded to cosmic on 2018-09-14 (9 days ago)
  modified.conffile..etc.apparmor.d.abstractions.evince: [modified]
  mtime.conffile..etc.apparmor.d.abstractions.evince: 2018-09-24T11:35:41.904158

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1794064/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1933117] Re: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule

2021-09-18 Thread Jamie Strandboge
** 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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1933117

Title:
  ufw delete can confuse protocol-specific rule with otherwise matching
  'proto any' rule

Status in ufw:
  Fix Released
Status in ufw package in Ubuntu:
  In Progress

Bug description:
  UFW versions 0.35 (on Ubuntu 16.04 LTS) and 0.36 (on Ubuntu 20.04 LTS)

  If a rule is inserted without specifying the protocol, it will default
  to both udp and tcp. If a second rule is inserted earlier in the order
  that specifies the protocol but is otherwise identical, UFW will
  delete the wrong rule if the first rule is deleted.

  This is repeatable with the following script:

  ufw insert 1 allow from 1.1.1.1/26 to any port 22
  ufw insert 2 allow from 1.2.3.4/26 to any port 22
  ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp
  iptables -L -n | grep -A 6 "Chain ufw-user-input"
  yes | ufw delete 3
  iptables -L -n | grep -A 4 "Chain ufw-user-input"

  The output is as follows:

  Chain ufw-user-input (1 references)
  target prot opt source   destination
  ACCEPT tcp  --  1.2.3.0/26   0.0.0.0/0tcp dpt:22
  ACCEPT tcp  --  1.1.1.0/26   0.0.0.0/0tcp dpt:22
  ACCEPT udp  --  1.1.1.0/26   0.0.0.0/0udp dpt:22
  ACCEPT tcp  --  1.2.3.0/26   0.0.0.0/0tcp dpt:22
  ACCEPT udp  --  1.2.3.0/26   0.0.0.0/0udp dpt:22

  Chain ufw-user-input (1 references)
  target prot opt source   destination
  ACCEPT tcp  --  1.1.1.0/26   0.0.0.0/0tcp dpt:22
  ACCEPT udp  --  1.1.1.0/26   0.0.0.0/0udp dpt:22
  ACCEPT tcp  --  1.2.3.0/26   0.0.0.0/0tcp dpt:22

  UFW deleted the first rule for 1.2.3.0 and then the last rule for
  1.2.3.0, leaving the wrong rule remaining. Here is the ufw status:

  To Action  From
  -- --  
  22/tcp ALLOW   1.2.3.0/26
  22 ALLOW   1.1.1.0/26

  Mixing ALLOW and REJECT/DENY rules can further result in incorrect
  behavior due to this incorrect reordering. On port 22, this could
  render SSH remotely inaccessible.

  For example, if one had initially set up the following rule to port 22
  (TCP and UDP)...

  ufw insert 1 allow from 1.2.3.4 to any port 22

  ...and later wanted to further restrict it to only TCP, while
  explicitly rejecting any other port 22 connections...

  ufw insert 1 allow from 1.2.3.4 to any port 22 proto tcp
  ufw insert 2 reject from any to any port 22
  yes | ufw delete 3

  ...this would result in SSH becoming inaccessible.

  Instead if one had the initial configuration...

  ufw insert 1 reject from 1.0.0.0/8 to any port 22
  ufw insert 2 allow from any to any port 22

  ...which was later updated to be...

  ufw insert 1 reject from 1.0.0.0/8 to any port 22 proto tcp
  ufw insert 2 allow from any to any port 22 proto tcp
  yes | ufw delete 3

  ...this would result in 1.0.0.0/8 incorrectly being allowed to access
  port 22. While this is a contrived scenario, it is possible and
  reproducible.

  A reboot is required to fix the issue, as it reloads the configuration
  to the expected order.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/1933117/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1726856] Re: ufw does not start automatically at boot

2021-09-18 Thread Jamie Strandboge
@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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1726856

Title:
  ufw does not start automatically at boot

Status in ufw:
  Invalid
Status in ufw package in Ubuntu:
  Invalid
Status in ufw source package in Xenial:
  Invalid
Status in ufw source package in Bionic:
  Invalid
Status in ufw source package in Cosmic:
  Invalid
Status in ufw source package in Disco:
  Invalid

Bug description:
  Whenever I boot into 17.10 ufw is always inactive, even though
  /etc/ufw/ufw.conf has this:

  # Set to yes to start on boot. If setting this remotely, be sure to add a rule
  # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp'
  ENABLED=yes

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ufw 0.35-5
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 24 13:56:40 2017
  InstallationDate: Installed on 2015-04-01 (936 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.2)
  PackageArchitecture: all
  SourcePackage: ufw
  UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago)
  mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170

To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/1726856/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1726856] Re: ufw does not start automatically at boot

2021-09-18 Thread Jamie Strandboge
@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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1726856

Title:
  ufw does not start automatically at boot

Status in ufw:
  Invalid
Status in ufw package in Ubuntu:
  Invalid
Status in ufw source package in Xenial:
  Invalid
Status in ufw source package in Bionic:
  Invalid
Status in ufw source package in Cosmic:
  Invalid
Status in ufw source package in Disco:
  Invalid

Bug description:
  Whenever I boot into 17.10 ufw is always inactive, even though
  /etc/ufw/ufw.conf has this:

  # Set to yes to start on boot. If setting this remotely, be sure to add a rule
  # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp'
  ENABLED=yes

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ufw 0.35-5
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 24 13:56:40 2017
  InstallationDate: Installed on 2015-04-01 (936 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.2)
  PackageArchitecture: all
  SourcePackage: ufw
  UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago)
  mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170

To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/1726856/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1934931] Re: (X)ubuntu 20.04: GUFW and MS-Teams slow down traffic intermittently

2021-09-18 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1934931

Title:
  (X)ubuntu 20.04: GUFW and MS-Teams slow down traffic intermittently

Status in Gufw:
  Invalid
Status in ufw package in Ubuntu:
  Incomplete

Bug description:
  Thanks for Gufw!

  inxi -S output: Xubuntu standard LTS installation - Kernel:
  5.4.0-77-generic x86_64 bits: 64 Desktop: Xfce 4.14.2 Distro: Ubuntu
  20.04.2 LTS (Focal Fossa). GUFW 20.04.1, MS Teams 1.4.00.13653
  (64-Bit) (all up to date at the time of this report).

  ** Problem: 250 Mbit LAN connection slowing down *intermittently*, but 
reproducible, to a crawl of 300 kbit or less if Gufw is activated parallel to 
MS teams. 
  * Gufw is used with only basic settings provided after installation 
(in:denied/out:allowed and nothing else set, no further rules).
  * There has not to be any active call in teams, just running it seems to 
cause the problem after a while (<5 minutes).
  * After congestion for some time (minutes), the system may recover to full 
speed again, only to succumb again after a few minutes. 
  * Other parallel running programs' connections are slowed down as well in 
accordance, e.g. parallel samba file sharing download is affected as well.
  * Stopping teams restores the connection speed after a short while (~1 
minute).
  * Parallel connections to the LAN(router) are not inhibited, it is just the 
one computer. 

  Teams seems to switch ports after restarting (UDP6/~34nnn-4). I
  set up a range to be allowed within ports used by teams (e.g.
  3:5, allow in/outbound) to no avail, connections dropped still
  to low speed.

  Thanks and regards,
  Christoph

To manage notifications about this bug go to:
https://bugs.launchpad.net/gui-ufw/+bug/1934931/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1921350] Re: UFW hangs indefinitely on any action

2021-09-18 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1921350

Title:
  UFW hangs indefinitely on any action

Status in ufw package in Ubuntu:
  Expired

Bug description:
  When installing a new cloudserver (on Amazon EC2, if it makes a
  difference), UFW completely hangs on any command, for example ufw
  status. Interrupting it with Ctrl+C yields this backtrace:

  Traceback (most recent call last):
File "/usr/sbin/ufw", line 130, in 
  lock = create_lock(lockfile=lockfile, dryrun=pr.dryrun)
File "/usr/lib/python3/dist-packages/ufw/util.py", line 1112, in create_lock
  fcntl.lockf(lock, fcntl.LOCK_EX)
  KeyboardInterrupt

  The line numbers are always the same.

  The platform is Ubuntu Server 20.04 (Ubuntu 20.04.2 LTS), from the
  Amazon image. I have not seen this bug on other servers. UFW is
  version 0.36.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1921350/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 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

2021-09-18 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in 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

Status in ufw package in Ubuntu:
  Incomplete

Bug description:
  dont upgrade

  ProblemType: Package
  DistroRelease: Ubuntu 18.04
  Package: ufw 0.36-0ubuntu0.18.04.1
  Uname: Linux 3.18.14-17162658-QB35446819 aarch64
  ApportVersion: 2.20.9-0ubuntu7.21
  Architecture: arm64
  Date: Sat Dec 26 20:56:19 2020
  Df:
   Filesystem 1K-blocks Used Available Use% Mounted on
   rootfs  24604780 19261268   5251352  79% /
   tmpfs1434188 1020   1433168   1% /dev
  Dmesg:
   
  ErrorMessage: installed ufw package post-installation script subprocess 
returned error exit status 10
  PackageArchitecture: all
  Python3Details: /usr/bin/python3.6, Python 3.6.5, unpackaged
  PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, unpackaged
  RelatedPackageVersions:
   dpkg 1.19.0.5ubuntu2
   apt  1.6.1
  SourcePackage: ufw
  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
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1909373/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1898696] Re: add some deliminiter between ipv4 and ipv6 in ufw status

2021-09-18 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1898696

Title:
  add some deliminiter between ipv4 and ipv6 in ufw status

Status in ufw package in Ubuntu:
  Confirmed

Bug description:
  "ufw status numbered" shows all the rules in one block, numbered from top to 
bottom. First are the ipv4 rules, then the ipv6.
  This has led to some irritation.

  A user asked how to add a IPv4 rule to the end of the list.
  https://answers.launchpad.net/ubuntu/+source/ufw/+question/692096
  Inserting ipv6 rules to the correct position is not easy to understand
  https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1368411

  My suggestion is to at least add some separator between the ipv4 and ipv6 
rules in the output of "ufw status". A blank line, or a comment line (# IPv6 
rules:) would be fine.
  This would indicate that not both rule lists, but only one of them, is 
applied to a connection.

  ## output suggestion:

  Status: active

   To Action  From
   -- --  
  [ 1] 22/tcp ALLOW INAnywhere  
  [ 2] 8080:8090/tcp  ALLOW INAnywhere   # mywww
  [ 3] WWW Full   ALLOW INAnywhere  
   # IPv6 rules:
  [ 4] 22/tcp (v6)ALLOW INAnywhere (v6) 
  [ 5] 8080:8090/tcp (v6) ALLOW INAnywhere (v6)  # mywww
  [ 6] WWW Full (v6)  ALLOW INAnywhere (v6)

  
  ## system info
  ufw --version: ufw 0.35

   side note
  But maybe this is irrelevant as long as the future plans of ufw are unclear. 
(https://answers.launchpad.net/ubuntu/+source/ufw/+question/692803)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1898696/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1911637] Re: Another app is currently holding the xtables lock

2021-09-18 Thread Jamie Strandboge
** Changed in: ufw
   Status: New => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1911637

Title:
  Another app is currently holding the xtables lock

Status in ufw:
  Triaged
Status in ufw package in Ubuntu:
  Confirmed
Status in ufw package in Debian:
  New

Bug description:
  Version: ufw 0.36 (via Debian buster 0.36-1 deb-package)

  I'm using ufw together with fail2ban, and often I get an error while
  fail2ban is trying to ban an ip:

  ```
  ERROR: initcaps
  [Errno 2] Another app is currently holding the xtables lock. Perhaps you want 
to use the -w option?

  ```

  it seems that in utils.py, get_netfilter_capabilities(...) iptables is
  called without "-w" flag to wait for the table lock

  perhaps the checks should include this parameter to avoid leaving
  temporary tables behind (and breaking fail2ban, but thats a different
  story ...)?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/1911637/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1911637] Re: Another app is currently holding the xtables lock

2021-09-18 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1911637

Title:
  Another app is currently holding the xtables lock

Status in ufw:
  Triaged
Status in ufw package in Ubuntu:
  Confirmed
Status in ufw package in Debian:
  New

Bug description:
  Version: ufw 0.36 (via Debian buster 0.36-1 deb-package)

  I'm using ufw together with fail2ban, and often I get an error while
  fail2ban is trying to ban an ip:

  ```
  ERROR: initcaps
  [Errno 2] Another app is currently holding the xtables lock. Perhaps you want 
to use the -w option?

  ```

  it seems that in utils.py, get_netfilter_capabilities(...) iptables is
  called without "-w" flag to wait for the table lock

  perhaps the checks should include this parameter to avoid leaving
  temporary tables behind (and breaking fail2ban, but thats a different
  story ...)?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/1911637/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1911637] Re: Another app is currently holding the xtables lock

2021-09-18 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1911637

Title:
  Another app is currently holding the xtables lock

Status in ufw:
  Triaged
Status in ufw package in Ubuntu:
  Confirmed
Status in ufw package in Debian:
  New

Bug description:
  Version: ufw 0.36 (via Debian buster 0.36-1 deb-package)

  I'm using ufw together with fail2ban, and often I get an error while
  fail2ban is trying to ban an ip:

  ```
  ERROR: initcaps
  [Errno 2] Another app is currently holding the xtables lock. Perhaps you want 
to use the -w option?

  ```

  it seems that in utils.py, get_netfilter_capabilities(...) iptables is
  called without "-w" flag to wait for the table lock

  perhaps the checks should include this parameter to avoid leaving
  temporary tables behind (and breaking fail2ban, but thats a different
  story ...)?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/1911637/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1938005] Re: ufw ignores rules

2021-08-16 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1938005

Title:
  ufw ignores rules

Status in ufw package in Ubuntu:
  Incomplete

Bug description:
  With my setting I shouldn't be able to surf web, but I can do it (without 
proxy/vpn)
  This problem happens after `iptables -F` and only way to solve it, is to 
reboot PC. I tried `ufw reload` , too

  ProblemType: Bug
  DistroRelease: Ubuntu 21.04
  Package: ufw 0.36-7.1
  ProcVersionSignature: Ubuntu 5.11.0-25.27-generic 5.11.22
  Uname: Linux 5.11.0-25-generic x86_64
  ApportVersion: 2.20.11-0ubuntu65.1
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: XFCE
  Date: Mon Jul 26 11:53:17 2021
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2021-06-17 (38 days ago)
  InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420)
  PackageArchitecture: all
  SourcePackage: ufw
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.default.ufw: 2021-07-25T22:22:29.221649

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1938005/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1938005] Re: ufw ignores rules

2021-08-07 Thread Jamie Strandboge
/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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1938005

Title:
  ufw ignores rules

Status in ufw package in Ubuntu:
  Incomplete

Bug description:
  With my setting I shouldn't be able to surf web, but I can do it (without 
proxy/vpn)
  This problem happens after `iptables -F` and only way to solve it, is to 
reboot PC. I tried `ufw reload` , too

  ProblemType: Bug
  DistroRelease: Ubuntu 21.04
  Package: ufw 0.36-7.1
  ProcVersionSignature: Ubuntu 5.11.0-25.27-generic 5.11.22
  Uname: Linux 5.11.0-25-generic x86_64
  ApportVersion: 2.20.11-0ubuntu65.1
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: XFCE
  Date: Mon Jul 26 11:53:17 2021
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2021-06-17 (38 days ago)
  InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420)
  PackageArchitecture: all
  SourcePackage: ufw
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.default.ufw: 2021-07-25T22:22:29.221649

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1938005/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1938005] Re: ufw ignores rules

2021-08-06 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1938005

Title:
  ufw ignores rules

Status in ufw package in Ubuntu:
  Invalid

Bug description:
  With my setting I shouldn't be able to surf web, but I can do it (without 
proxy/vpn)
  This problem happens after `iptables -F` and only way to solve it, is to 
reboot PC. I tried `ufw reload` , too

  ProblemType: Bug
  DistroRelease: Ubuntu 21.04
  Package: ufw 0.36-7.1
  ProcVersionSignature: Ubuntu 5.11.0-25.27-generic 5.11.22
  Uname: Linux 5.11.0-25-generic x86_64
  ApportVersion: 2.20.11-0ubuntu65.1
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: XFCE
  Date: Mon Jul 26 11:53:17 2021
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2021-06-17 (38 days ago)
  InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420)
  PackageArchitecture: all
  SourcePackage: ufw
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.default.ufw: 2021-07-25T22:22:29.221649

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1938005/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1921350] Re: UFW hangs indefinitely on any action

2021-03-25 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1921350

Title:
  UFW hangs indefinitely on any action

Status in ufw package in Ubuntu:
  Incomplete

Bug description:
  When installing a new cloudserver (on Amazon EC2, if it makes a
  difference), UFW completely hangs on any command, for example ufw
  status. Interrupting it with Ctrl+C yields this backtrace:

  Traceback (most recent call last):
File "/usr/sbin/ufw", line 130, in 
  lock = create_lock(lockfile=lockfile, dryrun=pr.dryrun)
File "/usr/lib/python3/dist-packages/ufw/util.py", line 1112, in create_lock
  fcntl.lockf(lock, fcntl.LOCK_EX)
  KeyboardInterrupt

  The line numbers are always the same.

  The platform is Ubuntu Server 20.04 (Ubuntu 20.04.2 LTS), from the
  Amazon image. I have not seen this bug on other servers. UFW is
  version 0.36.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1921350/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1914816] Re: ufw not logging if it decides to stop all traffic ? Confused

2021-03-01 Thread Jamie Strandboge
Thanks for the additional information! :)

** Changed in: ufw (Ubuntu)
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1914816

Title:
  ufw not logging if it decides to stop all traffic ?  Confused

Status in ufw package in Ubuntu:
  Invalid

Bug description:
  Sorry, this is going to be a very bad report.  Here's what I did:
  - installed gufw and enabled it, no rules, just default incoming=deny 
outgoing=accept
  - rebooted
  - Ethernet says it connected
  - no network access; ping 1.1.1.1 fails
  - launch gufw, and it says it's disabled (the whole firewall)
  - I think eventually I figured out that iptables had been emptied and INPUT 
chain set to DROP

  After many travails, I captured a piece of dmesg output as the system
  was booting, and I think it shows ufw trying to check IPv6 status and
  deciding to stop everything.  At least logging (which was set to full
  in gufw) suddenly stops.

  In network manager, I've tried to say "ignore IPv6".  I'm not sure if
  this trouble is related to fiddling with the "only work if IPv4 is
  enabled" check-box, which seems to have a ToolTip that is exactly
  backwards.  My ISP does not give IPv6 service.  I've tried many
  settings of the IPv6 drop-down in System Settings / Network GUI,
  setting and clearing the IPv4 and IPv6 required check-boxes, etc.

  So, I'm totally confused, but I think the log shows that logging
  suddenly stops (from full to zero), which must mean ufw detected some
  condition that made it empty out the iptables and set everything to
  DROP ?  If so, ufw should have logged a message saying it was doing
  so, and I don't see such a message.  So, if I'm right, at least this
  is a feature request that ufw should log a message when it decides to
  stop all IPv4 or IPv6 traffic and/or stop logging and/or wipe out all
  rules.

  Sorry about the mess of a report.

  I'm using Kubuntu 20.10, gufw 20.10.0-0ubuntu1, ufw 0.36-7

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: ufw (not installed)
  ProcVersionSignature: Ubuntu 5.8.0-41.46-generic 5.8.18
  Uname: Linux 5.8.0-41-generic x86_64
  ApportVersion: 2.20.11-0ubuntu50.5
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: KDE
  Date: Fri Feb  5 20:35:18 2021
  InstallationDate: Installed on 2021-02-03 (2 days ago)
  InstallationMedia: Kubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022)
  SourcePackage: ufw
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1914816/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1914816] Re: ufw not logging if it decides to stop all traffic ? Confused

2021-03-01 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1914816

Title:
  ufw not logging if it decides to stop all traffic ?  Confused

Status in ufw package in Ubuntu:
  Invalid

Bug description:
  Sorry, this is going to be a very bad report.  Here's what I did:
  - installed gufw and enabled it, no rules, just default incoming=deny 
outgoing=accept
  - rebooted
  - Ethernet says it connected
  - no network access; ping 1.1.1.1 fails
  - launch gufw, and it says it's disabled (the whole firewall)
  - I think eventually I figured out that iptables had been emptied and INPUT 
chain set to DROP

  After many travails, I captured a piece of dmesg output as the system
  was booting, and I think it shows ufw trying to check IPv6 status and
  deciding to stop everything.  At least logging (which was set to full
  in gufw) suddenly stops.

  In network manager, I've tried to say "ignore IPv6".  I'm not sure if
  this trouble is related to fiddling with the "only work if IPv4 is
  enabled" check-box, which seems to have a ToolTip that is exactly
  backwards.  My ISP does not give IPv6 service.  I've tried many
  settings of the IPv6 drop-down in System Settings / Network GUI,
  setting and clearing the IPv4 and IPv6 required check-boxes, etc.

  So, I'm totally confused, but I think the log shows that logging
  suddenly stops (from full to zero), which must mean ufw detected some
  condition that made it empty out the iptables and set everything to
  DROP ?  If so, ufw should have logged a message saying it was doing
  so, and I don't see such a message.  So, if I'm right, at least this
  is a feature request that ufw should log a message when it decides to
  stop all IPv4 or IPv6 traffic and/or stop logging and/or wipe out all
  rules.

  Sorry about the mess of a report.

  I'm using Kubuntu 20.10, gufw 20.10.0-0ubuntu1, ufw 0.36-7

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: ufw (not installed)
  ProcVersionSignature: Ubuntu 5.8.0-41.46-generic 5.8.18
  Uname: Linux 5.8.0-41-generic x86_64
  ApportVersion: 2.20.11-0ubuntu50.5
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: KDE
  Date: Fri Feb  5 20:35:18 2021
  InstallationDate: Installed on 2021-02-03 (2 days ago)
  InstallationMedia: Kubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022)
  SourcePackage: ufw
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1914816/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 881137] Re: UFW does not clean iptables setting from /etc/ufw/before.rules

2021-02-13 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/881137

Title:
  UFW does not clean iptables setting from /etc/ufw/before.rules

Status in ufw package in Ubuntu:
  Won't Fix

Bug description:
  Adding some additional settings to /etc/ufw/before.rules is not
  deleted when ufw is stopped.

  I added these lines at top of file /etc/ufw/before.rules

  *nat
  :POSTROUTING ACCEPT [0:0]
  -A POSTROUTING -o eth0 -j MASQUERADE
  COMMIT

  Then I reloaded ufw firewall with command: ufw reload. Output from
  iptables-save

  $ iptables-save -t nat
  *nat
  :PREROUTING ACCEPT [4:478]
  :INPUT ACCEPT [4:478]
  :OUTPUT ACCEPT [0:0]
  :POSTROUTING ACCEPT [0:0]
  -A POSTROUTING -o eth0 -j MASQUERADE 
  COMMIT

  Then I reloaded ufw firewall again:

  $ iptables-save -t nat
  *nat
  :PREROUTING ACCEPT [4:478]
  :INPUT ACCEPT [4:478]
  :OUTPUT ACCEPT [0:0]
  :POSTROUTING ACCEPT [0:0]
  -A POSTROUTING -o eth0 -j MASQUERADE 
  -A POSTROUTING -o eth0 -j MASQUERADE 
  COMMIT

  And ufw reload again

  $ iptables-save -t nat
  *nat
  :PREROUTING ACCEPT [4:478]
  :INPUT ACCEPT [4:478]
  :OUTPUT ACCEPT [0:0]
  :POSTROUTING ACCEPT [0:0]
  -A POSTROUTING -o eth0 -j MASQUERADE 
  -A POSTROUTING -o eth0 -j MASQUERADE 
  -A POSTROUTING -o eth0 -j MASQUERADE
  COMMIT

  And again and postrouting is never deleted when ufw is stopped and
  added again when stared. Same happen if I stop ufw firewall with: $
  stop ufw. nat lines are not cleaned.

  UFW should remove all iptables settings specified in config files
  after ufw is stopped! This can be dangerous if apt-get is updating
  some ufw files and scripts needs to reload ufw (some lines will be
  more times).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/881137/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1914816] Re: ufw not logging if it decides to stop all traffic ? Confused

2021-02-13 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1914816

Title:
  ufw not logging if it decides to stop all traffic ?  Confused

Status in ufw package in Ubuntu:
  Incomplete

Bug description:
  Sorry, this is going to be a very bad report.  Here's what I did:
  - installed gufw and enabled it, no rules, just default incoming=deny 
outgoing=accept
  - rebooted
  - Ethernet says it connected
  - no network access; ping 1.1.1.1 fails
  - launch gufw, and it says it's disabled (the whole firewall)
  - I think eventually I figured out that iptables had been emptied and INPUT 
chain set to DROP

  After many travails, I captured a piece of dmesg output as the system
  was booting, and I think it shows ufw trying to check IPv6 status and
  deciding to stop everything.  At least logging (which was set to full
  in gufw) suddenly stops.

  In network manager, I've tried to say "ignore IPv6".  I'm not sure if
  this trouble is related to fiddling with the "only work if IPv4 is
  enabled" check-box, which seems to have a ToolTip that is exactly
  backwards.  My ISP does not give IPv6 service.  I've tried many
  settings of the IPv6 drop-down in System Settings / Network GUI,
  setting and clearing the IPv4 and IPv6 required check-boxes, etc.

  So, I'm totally confused, but I think the log shows that logging
  suddenly stops (from full to zero), which must mean ufw detected some
  condition that made it empty out the iptables and set everything to
  DROP ?  If so, ufw should have logged a message saying it was doing
  so, and I don't see such a message.  So, if I'm right, at least this
  is a feature request that ufw should log a message when it decides to
  stop all IPv4 or IPv6 traffic and/or stop logging and/or wipe out all
  rules.

  Sorry about the mess of a report.

  I'm using Kubuntu 20.10, gufw 20.10.0-0ubuntu1, ufw 0.36-7

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: ufw (not installed)
  ProcVersionSignature: Ubuntu 5.8.0-41.46-generic 5.8.18
  Uname: Linux 5.8.0-41-generic x86_64
  ApportVersion: 2.20.11-0ubuntu50.5
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: KDE
  Date: Fri Feb  5 20:35:18 2021
  InstallationDate: Installed on 2021-02-03 (2 days ago)
  InstallationMedia: Kubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022)
  SourcePackage: ufw
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1914816/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1897369] Re: apparmor: Allow cups-browsed to change nice value (CAP_SYS_NICE)

2020-12-01 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to cups in Ubuntu.
https://bugs.launchpad.net/bugs/1897369

Title:
  apparmor: Allow cups-browsed to change nice value (CAP_SYS_NICE)

Status in cups package in Ubuntu:
  Confirmed

Bug description:
  In Ubuntu 20.04.1 with *cups-browsed* 1.27.4-1, apparmor prevents
  `/usr/sbin/cups-browsed` to change its nice value.

  $ sudo dmesg | grep apparmor
  [541870.509461] audit: type=1400 audit(1600898428.089:60): 
apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" 
pid=62030 comm="cups-browsed" capability=23  capname="sys_nice"
  [628298.779668] audit: type=1400 audit(1600984854.115:61): 
apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" 
pid=66850 comm="cups-browsed" capability=23  capname="sys_nice"
  [714667.424963] audit: type=1400 audit(1601071220.527:62): 
apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" 
pid=76828 comm="cups-browsed" capability=23  capname="sys_nice"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1897369/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1904192] Re: ebtables can not rename just created chain

2020-11-18 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1904192

Title:
  ebtables can not rename just created chain

Status in iptables:
  Unknown
Status in iptables package in Ubuntu:
  Fix Committed
Status in iptables source package in Groovy:
  In Progress
Status in iptables package in Debian:
  Unknown
Status in iptables package in Fedora:
  Fix Committed

Bug description:
  [SRU]

   * Changes that went into 1.8.5 ave broken the errno handling.
 In particular loading extensions. Due to that it has become
 impossible to rename rules.

   * Upstream has created a fix and this backports that change to
 Ubuntu
 => 
http://git.netfilter.org/iptables/commit/?id=55b7c71dce7144f4dc0297c17abf0f04879ee247

  [Test Case]

   * # ebtables -t nat -N foo
 # ebtables -t nat -E foo bar
 ebtables v1.8.5 (nf_tables): Chain 'foo' doesn't exists

   * with the fix the above command sequence works

  [Where problems could occur]

   * The change moved code from nft_chain_user_rename to do_commandeb and 
 therefore in theory any ebtables/xtables subcommand could be affected.
 Yet what it does is just resetting the error code in a better place, so 
 while it "could" affect every subcommand it should (tm) not do so.
 

  [Other Info]
   
   * n/a

  
  ---

  Hi,
  I have an issue with ebtables that affects libvirt.
  While initially found in hirsute I had to realize this is broken in
  Groovy and even Bionic (might be a different reason back then) as well right 
now.
  But working in Focal (witch matches my memory of it being good before [1]).

  I was isolating the commands that libvirt runs (identical between Focal
  and Hirsute) to find a simplified trigger. Gladly I found one that leaves
  libvirt and other components out of the equation.
  The following works on focal, but fails on the other releases.

  Note: I checked which tool is in use and in both cases it is 
xtables-nft-multi.
  /usr/sbin/ebtables -> /etc/alternatives/ebtables*
  /etc/alternatives/ebtables -> /usr/sbin/ebtables-nft*
  /usr/sbin/ebtables-nft -> xtables-nft-multi*
  So I converted the libvirt issued commands into xtables-nft-multi just to be
  sure in case a system to compare has other alternatives set.

  Focal (Good):
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 
testrule3-renamed
  

  Groovy/Hirsute (Fail):
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 
testrule3-renamed
  ebtables v1.8.5 (nf_tables): Chain 'testrule3' doesn't exists
  Try `ebtables -h' or 'ebtables --help' for more information.

  What might be the root cause for this?

  -- Old test instructions --

  As I said I was tracking a fail in libvirt so the test instructions initially
  were around that:

  # the following us done as 2nd level guest (to not mess with the host,
  # but works on bare metal jst as much)
  uvt-kvm create --host-passthrough --memory 2048 --cpu 4 --disk 16 
--password=ubuntu hirsute-kvm release=hirsute arch=amd64 label=daily
  # On guest then

  sudo apt update
  sudo apt install uvtool uvtool-libvirt
  uvt-simplestreams-libvirt --verbose sync --source 
http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=hirsute
  uvt-kvm create --disk 5 --machine-type ubuntu --password=ubuntu 
hirsute-2nd-lvm release=hirsute arch=amd64 label=daily
  uvt-kvm wait hirsute-2nd-lvm
  virsh shutdown hirsute-2nd-lvm
  virsh edit hirsute-2nd-lvm
  # add this to the network
    
  
    
  virsh start hirsute-2nd-lvm
    error: Failed to start domain hirsute-2nd-nwfilter
    error: internal error: applyDHCPOnlyRules failed - spoofing not protected!

  FYI: Get helpful log details with these in /etc/libvirt/libvirtd.conf
  log_filters="1:util.firewall"
  log_outputs="1:syslog:libvirtd"

  -- --

  [1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037

To manage notifications about this bug go to:
https://bugs.launchpad.net/iptables/+bug/1904192/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1898547] Re: neutron-linuxbridge-agent fails to start with iptables 1.8.5

2020-11-04 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1898547

Title:
  neutron-linuxbridge-agent fails to start with iptables 1.8.5

Status in iptables package in Ubuntu:
  Fix Committed
Status in neutron package in Ubuntu:
  Invalid
Status in iptables source package in Groovy:
  Triaged
Status in neutron source package in Groovy:
  Invalid
Status in iptables source package in Hirsute:
  Fix Committed
Status in neutron source package in Hirsute:
  Invalid

Bug description:
  Ubuntu Groovy (20.10)
  kernel 5.8.0-20-generic
  neutron-linuxbridge-agent: 2:17.0.0~git2020091014.215a541bd4-0ubuntu1
  iptables: 1.8.5-3ubuntu1 (nf_tables)
  iptables-restore points to xtables-nft-multi

  After upgrading iptables from 1.8.4 to 1.8.5 and rebooting the neutron 
network node, neutron-linuxbridge-agent didn't properly start anymore.
  The log file shows many errors like:

  2020-10-05 10:20:37.998 551 ERROR
  neutron.plugins.ml2.drivers.agent._common_agent ; Stdout: ; Stderr:
  iptables-restore: line 29 failed

  Downgrading iptables to 1.8.4 solves the problem.

  Trying to do what the linuxbridge agent does:
  2020-10-05 10:20:37.998 551 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent *filter
  2020-10-05 10:20:37.998 551 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent :FORWARD - [0:0]

  shows that

  iptables-restore 

[Touch-packages] [Bug 1899218] Re: Incorrect warning from apparmor_parser on force complained profiles

2020-10-12 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1899218

Title:
  Incorrect warning from apparmor_parser on force complained profiles

Status in apparmor package in Ubuntu:
  Fix Committed

Bug description:
  apparmor_parser on a force complained profile produces an incorrect
  warning message:

  $ sudo apparmor_parser -rW /etc/apparmor.d/usr.sbin.sssd
  Warning: found usr.sbin.sssd in /etc/apparmor.d/force-complain, forcing 
complain mode
  Warning from /etc/apparmor.d/usr.sbin.sssd (/etc/apparmor.d/usr.sbin.sssd 
line 54): Warning failed to create cache: usr.sbin.sssd

  Even though not generating the cache at all is expected, the warning
  should describe caching is disabled for force complained profiles
  instead of failure to create it.

  $ lsb_release -rd
  Description:  Ubuntu Groovy Gorilla (development branch)
  Release:  20.10

  $ apt-cache policy apparmor
  apparmor:
    Installed: 3.0.0~beta1-0ubuntu6
    Candidate: 3.0.0~beta1-0ubuntu6
    Version table:
   *** 3.0.0~beta1-0ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1899218/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1899046] Re: /usr/bin/aa-notify:ModuleNotFoundError:/usr/bin/aa-notify@39

2020-10-12 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1899046

Title:
  /usr/bin/aa-notify:ModuleNotFoundError:/usr/bin/aa-notify@39

Status in apparmor package in Ubuntu:
  Fix Committed

Bug description:
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
apparmor.  This problem was most recently seen with package version 
3.0.0~beta1-0ubuntu6, the problem page at 
https://errors.ubuntu.com/problem/69bb6832fe7b294bd7e2d75970fdc903f412c409 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker and are a software 
developer, you can request it at http://forms.canonical.com/reports/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1899046/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1726856] Re: ufw does not start automatically at boot

2020-10-05 Thread Jamie Strandboge
@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
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1726856

Title:
  ufw does not start automatically at boot

Status in ufw:
  Invalid
Status in ufw package in Ubuntu:
  Invalid
Status in ufw source package in Xenial:
  Invalid
Status in ufw source package in Bionic:
  Invalid
Status in ufw source package in Cosmic:
  Invalid
Status in ufw source package in Disco:
  Invalid

Bug description:
  Whenever I boot into 17.10 ufw is always inactive, even though
  /etc/ufw/ufw.conf has this:

  # Set to yes to start on boot. If setting this remotely, be sure to add a rule
  # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp'
  ENABLED=yes

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ufw 0.35-5
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 24 13:56:40 2017
  InstallationDate: Installed on 2015-04-01 (936 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.2)
  PackageArchitecture: all
  SourcePackage: ufw
  UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago)
  mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170

To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/1726856/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1894195] Re: FFe: Merge iptables 1.8.5-3 (main) from Debian sid (main)

2020-09-25 Thread Jamie Strandboge
** 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
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1894195

Title:
  FFe: Merge iptables 1.8.5-3 (main) from Debian sid (main)

Status in iptables package in Ubuntu:
  Fix Committed

Bug description:
  Please merge iptables 1.8.5-3 (main) from Debian sid (main)

  Explanation of FeatureFreeze exception:
  Current iptables is using the same upstream version in focal, which had 
problems with the nft backend and was then reverted to the legacy backend.
  1.8.5 has many fixes for the nft backend. For example these Debian bugs are 
fixed in 1.8.5:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950535
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961117
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968457
  Please merge it.

  Changelog entries since current groovy version 1.8.4-3ubuntu3:

  iptables (1.8.5-3) unstable; urgency=medium

    * [2d587e5] src:iptables: bump build-dep version on libnftnl to
  1.1.6

   -- Arturo Borrero Gonzalez   Tue, 25 Aug 2020
  11:56:55 +0200

  iptables (1.8.5-2) unstable; urgency=medium

    [ Alberto Molina Coballes ]
    * [d90516d] d/control: modify breaks and replaces fields (Closes: #949576)
    * [4754a45] d/not-installed: arch independ files
    * [780330f] d/tests/control: Run iptables-legacy-* tests explicitly

    [ Arturo Borrero Gonzalez ]
    * [6fb6557] d/patches: add -upstream-fix-xtables-translate.patch
  (Closes: #962724)

   -- Arturo Borrero Gonzalez   Wed, 24 Jun 2020
  10:56:19 +0200

  iptables (1.8.5-1) unstable; urgency=medium

    [ Debian Janitor ]
    * [c3deeb3] Wrap long lines in changelog entries: 1.8.2-1, 1.8.0-1~exp1,
    1.6.0-1.
    * [214468e] Update standards version to 4.5.0, no changes needed.

    [ Arturo Borrero Gonzalez ]
    * [eb1d7c5] New upstream version 1.8.5 (Closes: #950535)
    * [7a119db] d/patches: drop all patches
    * [ec63c87] libxtables12.symbols: add new symbol
    * [4056ce6] iptables: bump debhelper-compat to 13

   -- Arturo Borrero Gonzalez   Thu, 04 Jun 2020
  13:33:22 +0200

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1894195/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1887577] Re: DEP8: Invalid capability setuid

2020-09-23 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1887577

Title:
  DEP8: Invalid capability setuid

Status in apparmor package in Ubuntu:
  Fix Committed

Bug description:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-
  groovy/groovy/amd64/a/apparmor/20200713_202347_dd214@/log.gz

  Excuses is showing apparmor failing dep8 tests when they are triggered
  by another package.

  last time apparmor was uploaded was on May 14th, and this is the
  package under test:

  https://launchpad.net/ubuntu/+source/apparmor/2.13.3-7ubuntu6

  
  The errors are like this:
  FAIL: test_profile_newer_rewrites_cache (__main__.AAParserAltCacheTests)
  --
  Traceback (most recent call last):
File "/tmp/tmp.40nJ4LqRYT/parser/tst/testlib.py", line 50, in 
new_unittest_func
  return unittest_func(self)
File "./caching.py", line 448, in test_profile_newer_rewrites_cache
  self._generate_cache_file()
File "./caching.py", line 257, in _generate_cache_file
  self.run_cmd_check(cmd)
File "/tmp/tmp.40nJ4LqRYT/parser/tst/testlib.py", line 73, in run_cmd_check
  self.assertEqual(rc, expected_rc, "Got return code %d, expected 
%d\nCommand run: %s\nOutput: %s" % (rc, expected_rc, (' '.join(command)), 
report))
  AssertionError: 1 != 0 : Got return code 1, expected 0
  Command run: ../apparmor_parser --config-file=./parser.conf --base 
/tmp/aa-caching-s3l9wndt --skip-kernel-load --cache-loc 
/tmp/aa-caching-s3l9wndt/cache --cache-loc 
/tmp/aa-caching-s3l9wndt/aa-alt-cachezi43qt78 -q --write-cache -r 
/tmp/aa-caching-s3l9wndt/sbin.pingy
  Output: AppArmor parser error for /tmp/aa-caching-s3l9wndt/sbin.pingy in 
/tmp/aa-caching-s3l9wndt/suid-abstraction at line 3: Invalid capability setuid.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1887577/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore

2020-09-23 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  Fix Committed

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore

2020-09-22 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  Fix Committed

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1871148] Re: services start before apparmor profiles are loaded

2020-09-22 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1871148

Title:
  services start before apparmor profiles are loaded

Status in AppArmor:
  Invalid
Status in snapd:
  Fix Released
Status in apparmor package in Ubuntu:
  Fix Released
Status in snapd package in Ubuntu:
  Fix Released
Status in zsys package in Ubuntu:
  Invalid
Status in apparmor source package in Focal:
  Fix Released
Status in snapd source package in Focal:
  Fix Released
Status in zsys source package in Focal:
  Invalid

Bug description:
  Per discussion with Zyga in #snapd on Freenode, I have hit a race
  condition where services are being started by the system before
  apparmor has been started. I have a complete log of my system showing
  the effect somewhere within at https://paste.ubuntu.com/p/Jyx6gfFc3q/.
  Restarting apparmor using `sudo systemctl restart apparmor` is enough
  to bring installed snaps back to full functionality.

  Previously, when running any snap I would receive the following in the
  terminal:

  ---
  cannot change profile for the next exec call: No such file or directory
  snap-update-ns failed with code 1: File exists
  ---

  Updated to add for Jamie:

  $ snap version
  snap2.44.2+20.04
  snapd   2.44.2+20.04
  series  16
  ubuntu  20.04
  kernel  5.4.0-21-generic

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1871148/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore

2020-09-22 Thread Jamie Strandboge
** 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
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  In Progress

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895060] Re: [FFe] apparmor 3 upstream release

2020-09-22 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895060

Title:
  [FFe] apparmor 3 upstream release

Status in apparmor package in Ubuntu:
  Fix Committed

Bug description:
  As per the draft upstream release notes[1]:

  AppArmor 3.0 is a major new release of the AppArmor user space that makes
  an important change to policy development and support. Its focus is
  transitioning policy to the new features ABI and as such other new features
  have been limited.

  Apprmor 3.0 is a bridge release between older AppArmor 2.x policy and the
  newer AppArmor 3 style policy which requires the declaration of a features
  abi. As such AppArmor 3.0 will be a short lived release, and will not
  receive long term support. The following AppArmor 3.1 feature release is
  planned to be a regular release, please take this into account when
  including AppArmor 3.0 into a distro release.

  As such, Ubuntu 20.10 provides a great opportunity to introduce AppArmor3
  to Ubuntu and provide these new capabilities to users and system
  administrators. The short support lifespan of Ubuntu 20.10 ensures that
  there is alignment with the limited support lifetime of AppArmor 3.0 from
  upstream, whilst giving good exposure and opportunity to test and exercise
  the new features in AppArmor 3.x on the road to Ubuntu 22.04. A highlight
  of new features provided by AppArmor 3.0 include:

  - Policy now must declare the feature abi it was developed for if it is to
    use any new features. This ensures that old policy will not become
    incompatible with new kernels that support additional AppArmor features.
  - The use of profile names that are based on pathnames are deprecated.
  - Support for new kernel features (requires appropriate features abi
    tagging in policy)
    - upstream v8 network socket rules
    - xattr attachment conditionals
    - capabilities PERFMON and BPF
  - Improved compiler warnings and semantic checks
  - aa-status rewritten in C (previously was python) with additional features
    - supports use in systems/images where python is not available
    - supports kill, unconfined and mixed profile modes
  - Rewritten aa-notify (previously was perl, now python3)
    - shared backend with other python tools
    - support use of aa.CONFDIR instead of hard coded /etc/apparmor
    - improved message layout
  - Improved support for kernels that support LSM stacking
  - New utility aa-features-abi to extract and work with kernel abi features
  - New utility aa-load to load binary policy without calling the
    apparmor_parser
  - Support for profile modes
    - enforce (default when no mode flag is supplied)
    - kill (experimental)
    - unconfined (experimental)

  The use of the new AppArmor profile feature ABI includes a default
  configuration (for the Ubuntu packaged version of AppArmor proposed in this
  FFE) for the AppArmor features within the 5.4 Linux kernel - this ensures
  that all profiles provided in AppArmor3 for groovy will conform to this
  feature set and that upgrades to the kernel version (say to 5.8) that may
  include newer AppArmor confinement features will not result in additional
  policy denials as a result (since say the existing profile did not specify
  a rule for a new AppArmor feature which is now supported by the upgraded
  kernel). This ensures that there will be no regressions in application
  behaviour as a result of AppArmor kernel feature upgrades.

  TESTING

  This has been extensively tested by the security team - this includes
  following the documented Ubuntu merges test plan[2] for AppArmor and the
  extensive QA Regression Tests[3] for AppArmor as well. This ensures that the
  various applications that make heavy use of AppArmor (LXD, docker, lxc,
  dbus, libvirt, snapd etc) have all been exercised and no regressions have
  been observed. All tests have passed and demonstrated both apparmor and the
  various applications that use it to be working as expected.

  BUILD LOGS

  This is currently uploaded to groovy-proposed, build logs can be found on
  Launchpad at:
  https://launchpad.net/ubuntu/+source/apparmor/3.0.0~beta1-0ubuntu1

  INSTALL LOG

  See attached
  
(https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+attachment/5411197/+files
  /groovy-proposed-apparmor-install.log) for a log showing install of
  the packages from groovy-proposed

  [1] https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.0
  [2] https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor
  [3] 

[Touch-packages] [Bug 1895060] Re: [FFe] apparmor 3 upstream release

2020-09-21 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895060

Title:
  [FFe] apparmor 3 upstream release

Status in apparmor package in Ubuntu:
  Fix Committed

Bug description:
  As per the draft upstream release notes[1]:

  AppArmor 3.0 is a major new release of the AppArmor user space that makes
  an important change to policy development and support. Its focus is
  transitioning policy to the new features ABI and as such other new features
  have been limited.

  Apprmor 3.0 is a bridge release between older AppArmor 2.x policy and the
  newer AppArmor 3 style policy which requires the declaration of a features
  abi. As such AppArmor 3.0 will be a short lived release, and will not
  receive long term support. The following AppArmor 3.1 feature release is
  planned to be a regular release, please take this into account when
  including AppArmor 3.0 into a distro release.

  As such, Ubuntu 20.10 provides a great opportunity to introduce AppArmor3
  to Ubuntu and provide these new capabilities to users and system
  administrators. The short support lifespan of Ubuntu 20.10 ensures that
  there is alignment with the limited support lifetime of AppArmor 3.0 from
  upstream, whilst giving good exposure and opportunity to test and exercise
  the new features in AppArmor 3.x on the road to Ubuntu 22.04. A highlight
  of new features provided by AppArmor 3.0 include:

  - Policy now must declare the feature abi it was developed for if it is to
    use any new features. This ensures that old policy will not become
    incompatible with new kernels that support additional AppArmor features.
  - The use of profile names that are based on pathnames are deprecated.
  - Support for new kernel features (requires appropriate features abi
    tagging in policy)
    - upstream v8 network socket rules
    - xattr attachment conditionals
    - capabilities PERFMON and BPF
  - Improved compiler warnings and semantic checks
  - aa-status rewritten in C (previously was python) with additional features
    - supports use in systems/images where python is not available
    - supports kill, unconfined and mixed profile modes
  - Rewritten aa-notify (previously was perl, now python3)
    - shared backend with other python tools
    - support use of aa.CONFDIR instead of hard coded /etc/apparmor
    - improved message layout
  - Improved support for kernels that support LSM stacking
  - New utility aa-features-abi to extract and work with kernel abi features
  - New utility aa-load to load binary policy without calling the
    apparmor_parser
  - Support for profile modes
    - enforce (default when no mode flag is supplied)
    - kill (experimental)
    - unconfined (experimental)

  The use of the new AppArmor profile feature ABI includes a default
  configuration (for the Ubuntu packaged version of AppArmor proposed in this
  FFE) for the AppArmor features within the 5.4 Linux kernel - this ensures
  that all profiles provided in AppArmor3 for groovy will conform to this
  feature set and that upgrades to the kernel version (say to 5.8) that may
  include newer AppArmor confinement features will not result in additional
  policy denials as a result (since say the existing profile did not specify
  a rule for a new AppArmor feature which is now supported by the upgraded
  kernel). This ensures that there will be no regressions in application
  behaviour as a result of AppArmor kernel feature upgrades.

  TESTING

  This has been extensively tested by the security team - this includes
  following the documented Ubuntu merges test plan[2] for AppArmor and the
  extensive QA Regression Tests[3] for AppArmor as well. This ensures that the
  various applications that make heavy use of AppArmor (LXD, docker, lxc,
  dbus, libvirt, snapd etc) have all been exercised and no regressions have
  been observed. All tests have passed and demonstrated both apparmor and the
  various applications that use it to be working as expected.

  BUILD LOGS

  This is currently uploaded to groovy-proposed, build logs can be found on
  Launchpad at:
  https://launchpad.net/ubuntu/+source/apparmor/3.0.0~beta1-0ubuntu1

  INSTALL LOG

  See attached
  
(https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+attachment/5411197/+files
  /groovy-proposed-apparmor-install.log) for a log showing install of
  the packages from groovy-proposed

  [1] https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.0
  [2] https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor
  [3] 

[Touch-packages] [Bug 1895060] Re: [FFe] apparmor 3 upstream release

2020-09-18 Thread Jamie Strandboge
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
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895060

Title:
  [FFe] apparmor 3 upstream release

Status in apparmor package in Ubuntu:
  New

Bug description:
  As per the draft upstream release notes[1]:

  AppArmor 3.0 is a major new release of the AppArmor user space that makes
  an important change to policy development and support. Its focus is
  transitioning policy to the new features ABI and as such other new features
  have been limited.

  Apprmor 3.0 is a bridge release between older AppArmor 2.x policy and the
  newer AppArmor 3 style policy which requires the declaration of a features
  abi. As such AppArmor 3.0 will be a short lived release, and will not
  receive long term support. The following AppArmor 3.1 feature release is
  planned to be a regular release, please take this into account when
  including AppArmor 3.0 into a distro release.

  As such, Ubuntu 20.10 provides a great opportunity to introduce AppArmor3
  to Ubuntu and provide these new capabilities to users and system
  administrators. The short support lifespan of Ubuntu 20.10 ensures that
  there is alignment with the limited support lifetime of AppArmor 3.0 from
  upstream, whilst giving good exposure and opportunity to test and exercise
  the new features in AppArmor 3.x on the road to Ubuntu 22.04. A highlight
  of new features provided by AppArmor 3.0 include:

  - Policy now must declare the feature abi it was developed for if it is to
    use any new features. This ensures that old policy will not become
    incompatible with new kernels that support additional AppArmor features.
  - The use of profile names that are based on pathnames are deprecated.
  - Support for new kernel features (requires appropriate features abi
    tagging in policy)
    - upstream v8 network socket rules
    - xattr attachment conditionals
    - capabilities PERFMON and BPF
  - Improved compiler warnings and semantic checks
  - aa-status rewritten in C (previously was python) with additional features
    - supports use in systems/images where python is not available
    - supports kill, unconfined and mixed profile modes
  - Rewritten aa-notify (previously was perl, now python3)
    - shared backend with other python tools
    - support use of aa.CONFDIR instead of hard coded /etc/apparmor
    - improved message layout
  - Improved support for kernels that support LSM stacking
  - New utility aa-features-abi to extract and work with kernel abi features
  - New utility aa-load to load binary policy without calling the
    apparmor_parser
  - Support for profile modes
    - enforce (default when no mode flag is supplied)
    - kill (experimental)
    - unconfined (experimental)

  The use of the new AppArmor profile feature ABI includes a default
  configuration (for the Ubuntu packaged version of AppArmor proposed in this
  FFE) for the AppArmor features within the 5.4 Linux kernel - this ensures
  that all profiles provided in AppArmor3 for groovy will conform to this
  feature set and that upgrades to the kernel version (say to 5.8) that may
  include newer AppArmor confinement features will not result in additional
  policy denials as a result (since say the existing profile did not specify
  a rule for a new AppArmor feature which is now supported by the upgraded
  kernel). This ensures that there will be no regressions in application
  behaviour as a result of AppArmor kernel feature upgrades.

  TESTING

  This has been extensively tested by the security team - this includes
  following the documented Ubuntu merges test plan[2] for AppArmor and the
  extensive QA Regression Tests[3] for AppArmor as well. This ensures that the
  various applications that make heavy use of AppArmor (LXD, docker, lxc,
  dbus, libvirt, snapd etc) have all been exercised and no regressions have
  been observed. All tests have passed and demonstrated both apparmor and the
  various applications that use it to be working as expected.

  BUILD LOGS

  This is currently uploaded to groovy-proposed, build logs can be found on
  Launchpad at:
  https://launchpad.net/ubuntu/+source/apparmor/3.0.0~beta1-0ubuntu1

  INSTALL LOG

  See attached
  
(https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+attachment/5411197/+files
  /groovy-proposed-apparmor-install.log) for a log showing install of
  the packages from 

[Touch-packages] [Bug 1895060] Re: [FFe] apparmor 3 upstream release

2020-09-18 Thread Jamie Strandboge
FYI, 3.0.0~beta1-0ubuntu3 should address the dbus autopkgtest issue.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895060

Title:
  [FFe] apparmor 3 upstream release

Status in apparmor package in Ubuntu:
  New

Bug description:
  As per the draft upstream release notes[1]:

  AppArmor 3.0 is a major new release of the AppArmor user space that makes
  an important change to policy development and support. Its focus is
  transitioning policy to the new features ABI and as such other new features
  have been limited.

  Apprmor 3.0 is a bridge release between older AppArmor 2.x policy and the
  newer AppArmor 3 style policy which requires the declaration of a features
  abi. As such AppArmor 3.0 will be a short lived release, and will not
  receive long term support. The following AppArmor 3.1 feature release is
  planned to be a regular release, please take this into account when
  including AppArmor 3.0 into a distro release.

  As such, Ubuntu 20.10 provides a great opportunity to introduce AppArmor3
  to Ubuntu and provide these new capabilities to users and system
  administrators. The short support lifespan of Ubuntu 20.10 ensures that
  there is alignment with the limited support lifetime of AppArmor 3.0 from
  upstream, whilst giving good exposure and opportunity to test and exercise
  the new features in AppArmor 3.x on the road to Ubuntu 22.04. A highlight
  of new features provided by AppArmor 3.0 include:

  - Policy now must declare the feature abi it was developed for if it is to
    use any new features. This ensures that old policy will not become
    incompatible with new kernels that support additional AppArmor features.
  - The use of profile names that are based on pathnames are deprecated.
  - Support for new kernel features (requires appropriate features abi
    tagging in policy)
    - upstream v8 network socket rules
    - xattr attachment conditionals
    - capabilities PERFMON and BPF
  - Improved compiler warnings and semantic checks
  - aa-status rewritten in C (previously was python) with additional features
    - supports use in systems/images where python is not available
    - supports kill, unconfined and mixed profile modes
  - Rewritten aa-notify (previously was perl, now python3)
    - shared backend with other python tools
    - support use of aa.CONFDIR instead of hard coded /etc/apparmor
    - improved message layout
  - Improved support for kernels that support LSM stacking
  - New utility aa-features-abi to extract and work with kernel abi features
  - New utility aa-load to load binary policy without calling the
    apparmor_parser
  - Support for profile modes
    - enforce (default when no mode flag is supplied)
    - kill (experimental)
    - unconfined (experimental)

  The use of the new AppArmor profile feature ABI includes a default
  configuration (for the Ubuntu packaged version of AppArmor proposed in this
  FFE) for the AppArmor features within the 5.4 Linux kernel - this ensures
  that all profiles provided in AppArmor3 for groovy will conform to this
  feature set and that upgrades to the kernel version (say to 5.8) that may
  include newer AppArmor confinement features will not result in additional
  policy denials as a result (since say the existing profile did not specify
  a rule for a new AppArmor feature which is now supported by the upgraded
  kernel). This ensures that there will be no regressions in application
  behaviour as a result of AppArmor kernel feature upgrades.

  TESTING

  This has been extensively tested by the security team - this includes
  following the documented Ubuntu merges test plan[2] for AppArmor and the
  extensive QA Regression Tests[3] for AppArmor as well. This ensures that the
  various applications that make heavy use of AppArmor (LXD, docker, lxc,
  dbus, libvirt, snapd etc) have all been exercised and no regressions have
  been observed. All tests have passed and demonstrated both apparmor and the
  various applications that use it to be working as expected.

  BUILD LOGS

  This is currently uploaded to groovy-proposed, build logs can be found on
  Launchpad at:
  https://launchpad.net/ubuntu/+source/apparmor/3.0.0~beta1-0ubuntu1

  INSTALL LOG

  See attached
  
(https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+attachment/5411197/+files
  /groovy-proposed-apparmor-install.log) for a log showing install of
  the packages from groovy-proposed

  [1] https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.0
  [2] https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor
  [3] 
https://git.launchpad.net/qa-regression-testing/tree/scripts/test-apparmor.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : 

[Touch-packages] [Bug 1895060] Re: [FFe] apparmor 3 upstream release

2020-09-17 Thread Jamie Strandboge
FYI, the fix for the dbus issue is
https://gitlab.com/apparmor/apparmor/-/merge_requests/625. We're
preparing an ubuntu2 upload now.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895060

Title:
  [FFe] apparmor 3 upstream release

Status in apparmor package in Ubuntu:
  New

Bug description:
  As per the draft upstream release notes[1]:

  AppArmor 3.0 is a major new release of the AppArmor user space that makes
  an important change to policy development and support. Its focus is
  transitioning policy to the new features ABI and as such other new features
  have been limited.

  Apprmor 3.0 is a bridge release between older AppArmor 2.x policy and the
  newer AppArmor 3 style policy which requires the declaration of a features
  abi. As such AppArmor 3.0 will be a short lived release, and will not
  receive long term support. The following AppArmor 3.1 feature release is
  planned to be a regular release, please take this into account when
  including AppArmor 3.0 into a distro release.

  As such, Ubuntu 20.10 provides a great opportunity to introduce AppArmor3
  to Ubuntu and provide these new capabilities to users and system
  administrators. The short support lifespan of Ubuntu 20.10 ensures that
  there is alignment with the limited support lifetime of AppArmor 3.0 from
  upstream, whilst giving good exposure and opportunity to test and exercise
  the new features in AppArmor 3.x on the road to Ubuntu 22.04. A highlight
  of new features provided by AppArmor 3.0 include:

  - Policy now must declare the feature abi it was developed for if it is to
    use any new features. This ensures that old policy will not become
    incompatible with new kernels that support additional AppArmor features.
  - The use of profile names that are based on pathnames are deprecated.
  - Support for new kernel features (requires appropriate features abi
    tagging in policy)
    - upstream v8 network socket rules
    - xattr attachment conditionals
    - capabilities PERFMON and BPF
  - Improved compiler warnings and semantic checks
  - aa-status rewritten in C (previously was python) with additional features
    - supports use in systems/images where python is not available
    - supports kill, unconfined and mixed profile modes
  - Rewritten aa-notify (previously was perl, now python3)
    - shared backend with other python tools
    - support use of aa.CONFDIR instead of hard coded /etc/apparmor
    - improved message layout
  - Improved support for kernels that support LSM stacking
  - New utility aa-features-abi to extract and work with kernel abi features
  - New utility aa-load to load binary policy without calling the
    apparmor_parser
  - Support for profile modes
    - enforce (default when no mode flag is supplied)
    - kill (experimental)
    - unconfined (experimental)

  The use of the new AppArmor profile feature ABI includes a default
  configuration (for the Ubuntu packaged version of AppArmor proposed in this
  FFE) for the AppArmor features within the 5.4 Linux kernel - this ensures
  that all profiles provided in AppArmor3 for groovy will conform to this
  feature set and that upgrades to the kernel version (say to 5.8) that may
  include newer AppArmor confinement features will not result in additional
  policy denials as a result (since say the existing profile did not specify
  a rule for a new AppArmor feature which is now supported by the upgraded
  kernel). This ensures that there will be no regressions in application
  behaviour as a result of AppArmor kernel feature upgrades.

  TESTING

  This has been extensively tested by the security team - this includes
  following the documented Ubuntu merges test plan[2] for AppArmor and the
  extensive QA Regression Tests[3] for AppArmor as well. This ensures that the
  various applications that make heavy use of AppArmor (LXD, docker, lxc,
  dbus, libvirt, snapd etc) have all been exercised and no regressions have
  been observed. All tests have passed and demonstrated both apparmor and the
  various applications that use it to be working as expected.

  BUILD LOGS

  This is currently uploaded to groovy-proposed, build logs can be found on
  Launchpad at:
  https://launchpad.net/ubuntu/+source/apparmor/3.0.0~beta1-0ubuntu1

  INSTALL LOG

  See attached
  
(https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+attachment/5411197/+files
  /groovy-proposed-apparmor-install.log) for a log showing install of
  the packages from groovy-proposed

  [1] https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.0
  [2] https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor
  [3] 
https://git.launchpad.net/qa-regression-testing/tree/scripts/test-apparmor.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+subscriptions

-- 
Mailing list: 

[Touch-packages] [Bug 1895060] Re: [FFe] apparmor 3 upstream release

2020-09-16 Thread Jamie Strandboge
FYI, we're looking at the autopkgtest dbus issue now.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895060

Title:
  [FFe] apparmor 3 upstream release

Status in apparmor package in Ubuntu:
  New

Bug description:
  As per the draft upstream release notes[1]:

  AppArmor 3.0 is a major new release of the AppArmor user space that makes
  an important change to policy development and support. Its focus is
  transitioning policy to the new features ABI and as such other new features
  have been limited.

  Apprmor 3.0 is a bridge release between older AppArmor 2.x policy and the
  newer AppArmor 3 style policy which requires the declaration of a features
  abi. As such AppArmor 3.0 will be a short lived release, and will not
  receive long term support. The following AppArmor 3.1 feature release is
  planned to be a regular release, please take this into account when
  including AppArmor 3.0 into a distro release.

  As such, Ubuntu 20.10 provides a great opportunity to introduce AppArmor3
  to Ubuntu and provide these new capabilities to users and system
  administrators. The short support lifespan of Ubuntu 20.10 ensures that
  there is alignment with the limited support lifetime of AppArmor 3.0 from
  upstream, whilst giving good exposure and opportunity to test and exercise
  the new features in AppArmor 3.x on the road to Ubuntu 22.04. A highlight
  of new features provided by AppArmor 3.0 include:

  - Policy now must declare the feature abi it was developed for if it is to
    use any new features. This ensures that old policy will not become
    incompatible with new kernels that support additional AppArmor features.
  - The use of profile names that are based on pathnames are deprecated.
  - Support for new kernel features (requires appropriate features abi
    tagging in policy)
    - upstream v8 network socket rules
    - xattr attachment conditionals
    - capabilities PERFMON and BPF
  - Improved compiler warnings and semantic checks
  - aa-status rewritten in C (previously was python) with additional features
    - supports use in systems/images where python is not available
    - supports kill, unconfined and mixed profile modes
  - Rewritten aa-notify (previously was perl, now python3)
    - shared backend with other python tools
    - support use of aa.CONFDIR instead of hard coded /etc/apparmor
    - improved message layout
  - Improved support for kernels that support LSM stacking
  - New utility aa-features-abi to extract and work with kernel abi features
  - New utility aa-load to load binary policy without calling the
    apparmor_parser
  - Support for profile modes
    - enforce (default when no mode flag is supplied)
    - kill (experimental)
    - unconfined (experimental)

  The use of the new AppArmor profile feature ABI includes a default
  configuration (for the Ubuntu packaged version of AppArmor proposed in this
  FFE) for the AppArmor features within the 5.4 Linux kernel - this ensures
  that all profiles provided in AppArmor3 for groovy will conform to this
  feature set and that upgrades to the kernel version (say to 5.8) that may
  include newer AppArmor confinement features will not result in additional
  policy denials as a result (since say the existing profile did not specify
  a rule for a new AppArmor feature which is now supported by the upgraded
  kernel). This ensures that there will be no regressions in application
  behaviour as a result of AppArmor kernel feature upgrades.

  TESTING

  This has been extensively tested by the security team - this includes
  following the documented Ubuntu merges test plan[2] for AppArmor and the
  extensive QA Regression Tests[3] for AppArmor as well. This ensures that the
  various applications that make heavy use of AppArmor (LXD, docker, lxc,
  dbus, libvirt, snapd etc) have all been exercised and no regressions have
  been observed. All tests have passed and demonstrated both apparmor and the
  various applications that use it to be working as expected.

  BUILD LOGS

  This is currently uploaded to groovy-proposed, build logs can be found on
  Launchpad at:
  https://launchpad.net/ubuntu/+source/apparmor/3.0.0~beta1-0ubuntu1

  INSTALL LOG

  See attached
  
(https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+attachment/5411197/+files
  /groovy-proposed-apparmor-install.log) for a log showing install of
  the packages from groovy-proposed

  [1] https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.0
  [2] https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor
  [3] 
https://git.launchpad.net/qa-regression-testing/tree/scripts/test-apparmor.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net

[Touch-packages] [Bug 1880841] Re: usr.sbin.nscd needs unix socket access to @userdb-*

2020-09-09 Thread Jamie Strandboge
This will be fixed in the next apparmor upload.

** Changed in: apparmor (Ubuntu)
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1880841

Title:
  usr.sbin.nscd needs unix socket access to @userdb-*

Status in apparmor package in Ubuntu:
  In Progress

Bug description:
  This concerns apparmor-profiles 2.13.3-7ubuntu5 in Ubuntu focal.

  I use the usr.sbin.nscd profile in enforce mode, and am seeing the
  following messages in /var/log/syslog . I don't know if the SIGABRT is
  related:

  May 27 04:39:56 test-ubuntu64 kernel: [  199.392521] audit: type=1400 
audit(1590568796.975:76): apparmor="DENIED" operation="bind" profile="nscd" 
pid=1679 comm="nscd" family="unix" sock_type="dgram" protocol=0 
requested_mask="bind" denied_mask="bind" 
addr="@userdb-4a5d3fdcfb9afbd7fc75948800519358"
  May 27 04:40:17 test-ubuntu64 systemd[1]: nscd.service: Main process exited, 
code=killed, status=6/ABRT
  May 27 04:40:17 test-ubuntu64 systemd[1]: nscd.service: Failed with result 
'signal'.
  May 27 04:40:17 test-ubuntu64 systemd[1]: nscd.service: Scheduled restart 
job, restart counter is at 9.

  
  The @userdb-* binding looks like a systemd thing. Should a rule for this go 
into /etc/apparmor.d/abstractions/nameservice ?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1880841/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1887577] Re: DEP8: Invalid capability setuid

2020-09-09 Thread Jamie Strandboge
This will be fixed in the next apparmor upload.

** Changed in: apparmor (Ubuntu)
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1887577

Title:
  DEP8: Invalid capability setuid

Status in apparmor package in Ubuntu:
  In Progress

Bug description:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-
  groovy/groovy/amd64/a/apparmor/20200713_202347_dd214@/log.gz

  Excuses is showing apparmor failing dep8 tests when they are triggered
  by another package.

  last time apparmor was uploaded was on May 14th, and this is the
  package under test:

  https://launchpad.net/ubuntu/+source/apparmor/2.13.3-7ubuntu6

  
  The errors are like this:
  FAIL: test_profile_newer_rewrites_cache (__main__.AAParserAltCacheTests)
  --
  Traceback (most recent call last):
File "/tmp/tmp.40nJ4LqRYT/parser/tst/testlib.py", line 50, in 
new_unittest_func
  return unittest_func(self)
File "./caching.py", line 448, in test_profile_newer_rewrites_cache
  self._generate_cache_file()
File "./caching.py", line 257, in _generate_cache_file
  self.run_cmd_check(cmd)
File "/tmp/tmp.40nJ4LqRYT/parser/tst/testlib.py", line 73, in run_cmd_check
  self.assertEqual(rc, expected_rc, "Got return code %d, expected 
%d\nCommand run: %s\nOutput: %s" % (rc, expected_rc, (' '.join(command)), 
report))
  AssertionError: 1 != 0 : Got return code 1, expected 0
  Command run: ../apparmor_parser --config-file=./parser.conf --base 
/tmp/aa-caching-s3l9wndt --skip-kernel-load --cache-loc 
/tmp/aa-caching-s3l9wndt/cache --cache-loc 
/tmp/aa-caching-s3l9wndt/aa-alt-cachezi43qt78 -q --write-cache -r 
/tmp/aa-caching-s3l9wndt/sbin.pingy
  Output: AppArmor parser error for /tmp/aa-caching-s3l9wndt/sbin.pingy in 
/tmp/aa-caching-s3l9wndt/suid-abstraction at line 3: Invalid capability setuid.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1887577/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1889699] Re: Brave is not included in the Ubuntu helpers

2020-09-09 Thread Jamie Strandboge
Thanks for the patch! I'll get this incorporated into the next apparmor
upload.

** Changed in: apparmor (Ubuntu)
   Status: New => In Progress

** Changed in: apparmor (Ubuntu)
 Assignee: (unassigned) => Jamie Strandboge (jdstrand)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1889699

Title:
  Brave is not included in the Ubuntu helpers

Status in apparmor package in Ubuntu:
  In Progress

Bug description:
  The Brave browser is not included in /etc/apparmor.d/abstractions
  /ubuntu-browsers and /etc/apparmor.d/abstractions/ubuntu-helpers which
  means that when it's set as a default browser by a user, profiles like
  /etc/apparmor.d/usr.bin.evince break.

  In this case, it means that users can't click on web links in PDFs for
  example: https://community.brave.com/t/brave-does-not-open-links-
  clicked-when-set-as-default-browser/146608/9

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1889699/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1891338] Re: apparmor misconfigured for envice

2020-09-09 Thread Jamie Strandboge
You are right that there are two places this is defined: in
/etc/apparmor.d/abstractions/ubuntu-browsers.d/ubuntu-integration and in
/etc/apparmor.d/usr.bin.evince.

I'll adjust apparmor to fix ubuntu-integration to use the exo-open
abstraction.

There is an evince task though because we don't want it to use the
ubuntu-integration abstraction. Instead the exo-open stanza in the
usr.bin.evince should just include the exo-open abstraction. Ie, replace
this:

  # For Xubuntu to launch the browser
  /usr/bin/exo-open ixr,
  /usr/lib/@{multiarch}/xfce4/exo-1/exo-helper-1 ixr,
  /etc/xdg/xdg-xubuntu/xfce4/helpers.rc r,
  /etc/xdg/xfce4/helpers.rc r,

with this:

  # For Xubuntu to launch the browser
  #include 


** Also affects: evince (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: apparmor (Ubuntu)
   Status: New => In Progress

** Changed in: evince (Ubuntu)
   Status: New => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1891338

Title:
  apparmor misconfigured for envice

Status in apparmor package in Ubuntu:
  In Progress
Status in evince package in Ubuntu:
  Triaged

Bug description:
  On a fully up to date xubuntu 20-04 system, when i run evince and
  click on a link, it fails to follow that link in my browser. This kind
  of thing happens when you are reading a technical paper and want to
  follow one of the references and click on the doi or url.

  When i click on the link i get a box that i cannot copy from that says:
  Failed to launch preferred application for category "WebBrowser".

  Failed to execute child process "/usr/lib/x86_64-linux-gnu/xfce4/exo-2
  /exo-helper-2"(Permission denied).

  Did I say that it is annoying that i could not copy the text in this
  box!!

  The output of the ldd command you asked for is attached.

  I should also point out that this worked fine under xubuntu 18.04.

  I had originally posted this as an additional comment on
  https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1869159?comments=all
  but https://launchpad.net/~seb128 said that I should submit this as a
  separate bug because this is likely an apparmor configuration problem
  that is similar to the ancient bug
  https://bugs.launchpad.net/bugs/987578.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1891338/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895060] [NEW] [FFe] apparmor 3 upstream release

2020-09-09 Thread Jamie Strandboge
Public bug reported:

To be filled in

** Affects: apparmor (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895060

Title:
  [FFe] apparmor 3 upstream release

Status in apparmor package in Ubuntu:
  New

Bug description:
  To be filled in

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1385013] Re: proper fix for apparmor mediation of lower (encrypted) filesystem

2020-08-26 Thread Jamie Strandboge
I'm bumping the priority down to Undecided as its been almost 6 years--
it clearly isn't critical. :)

** Changed in: apparmor (Ubuntu)
 Assignee: NYEIN LIN THU (mgnyein) => (unassigned)

** Changed in: apparmor (Ubuntu)
   Importance: Critical => Undecided

** Changed in: ecryptfs-utils (Ubuntu)
   Importance: Critical => Undecided

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1385013

Title:
  proper fix for apparmor mediation of lower (encrypted) filesystem

Status in apparmor package in Ubuntu:
  Confirmed
Status in ecryptfs-utils package in Ubuntu:
  Confirmed

Bug description:
  This is the proper fix for LP: #359338 which is needed for user data
  encryption.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1385013/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1891810] Re: Missing openat2 syscall, causes problems for fuse-overlayfs in nspawn containers

2020-08-17 Thread Jamie Strandboge
** Also affects: libseccomp (Ubuntu Groovy)
   Importance: Undecided
 Assignee: Alex Murray (alexmurray)
   Status: New

** Also affects: libseccomp (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: libseccomp (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: libseccomp (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Changed in: libseccomp (Ubuntu Focal)
 Assignee: (unassigned) => Alex Murray (alexmurray)

** Changed in: libseccomp (Ubuntu Bionic)
 Assignee: (unassigned) => Alex Murray (alexmurray)

** Changed in: libseccomp (Ubuntu Xenial)
 Assignee: (unassigned) => Alex Murray (alexmurray)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1891810

Title:
  Missing openat2 syscall, causes problems for fuse-overlayfs in nspawn
  containers

Status in libseccomp package in Ubuntu:
  New
Status in libseccomp source package in Xenial:
  New
Status in libseccomp source package in Bionic:
  New
Status in libseccomp source package in Focal:
  New
Status in libseccomp source package in Groovy:
  New

Bug description:
  The version of libseccomp2 in bionic does not know about the openat2
  syscall.

  In my particular usecase, I was trying to run podman/buildah in an
  nspawn container, using fuse-overlayfs. This leads to peculiar failure
  modes as described in this issue:

  https://github.com/containers/fuse-overlayfs/issues/220

  This could well cause other problems, previously issues like that have
  affected snapd, etc.

  Backporting the master branch of libseccomp fixed this for me, but for
  an SRU a cherrypick of
  
https://github.com/seccomp/libseccomp/commit/b3206ad5645dceda89538ea8acc984078ab697ab
  might be sufficient...

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: libseccomp2 2.4.3-1ubuntu3.18.04.3
  ProcVersionSignature: Ubuntu 5.4.0-42.46~18.04.1-generic 5.4.44
  Uname: Linux 5.4.0-42-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.16
  Architecture: amd64
  Date: Sun Aug 16 17:35:09 2020
  Dependencies:
   gcc-8-base 8.4.0-1ubuntu1~18.04
   libc6 2.27-3ubuntu1.2
   libgcc1 1:8.4.0-1ubuntu1~18.04
  ProcEnviron:
   TERM=screen.xterm-256color
   PATH=(custom, no user)
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: libseccomp
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1891810/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2020-08-04 Thread Jamie Strandboge
I agree that a new bug should be filed. When doing so, please attach any
relevant policy violations from journalctl to the bug.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ibus in Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

Status in ibus:
  Fix Released
Status in apparmor package in Ubuntu:
  Fix Released
Status in ibus package in Ubuntu:
  Fix Released
Status in im-config package in Ubuntu:
  Fix Released
Status in snapd package in Ubuntu:
  Fix Released
Status in apparmor source package in Xenial:
  Fix Released
Status in im-config source package in Xenial:
  Fix Released
Status in snapd source package in Xenial:
  Fix Released
Status in apparmor source package in Yakkety:
  Fix Released
Status in im-config source package in Yakkety:
  Fix Released
Status in snapd source package in Yakkety:
  Fix Released

Bug description:
  = SRU im-config =
  [Impact]
  ibus-daemon by default uses a unix socket name of /tmp/dbus-... that is 
indistinguishable from dbus-daemon abstract sockets. While dbus-daemon has 
AppArmor mediation, ibus-daemon does not so it is important that its abstract 
socket not be confused with dbus-daemon's. By modifying ibus-daemon's start 
arguments to use "--address 'unix:tmpdir=/tmp/ibus'" AppArmor can continue 
mediating DBus abstract sockets like normal and also mediate access to the 
ibus-daemon-specific abstract socket via unix rules. This also tidies up the 
abstract socket paths so that it is clear which are for ibus-daemon, which for 
dbus-daemon, etc.

  The upload simply adjusts 21_ibus.rc to start ibus-daemon with "--
  address 'unix:tmpdir=/tmp/ibus'" and adds a comment. No compiled code
  changes are required.

  [Test Case]
  1. start a unity session before updating to the package in -proposed

  2. $ grep IBUS_ADDRESS ~/.config/ibus/bus/*-unix-0
  
IBUS_ADDRESS=unix:abstract=/tmp/dbus-Vyx8fGFA,guid=28e8e7e89f902c8d4e9d77c5557add76

  3. $ lsof -p $(pidof ibus-daemon) | grep '/dbus'
  ibus-daem 2973 jamie8u unix 0x  0t0   29606 
@/tmp/dbus-oxKYpN30 type=STREAM

  4. update the package in -proposed and perform '2' and '3'. The
  IBUS_ADDRESSES should be the same as before

  5. logout of unity, then log back in

  6. $ grep IBUS_ADDRESS ~/.config/ibus/bus/*-unix-0
  
IBUS_ADDRESS=unix:abstract=/tmp/ibus/dbus-SpxOl8Fc,guid=06d4bbeb07614c6dffbf221c57473f4e

  (notice '/tmp/ibus/' in the path)

  7. $ lsof -p $(pidof ibus-daemon) | grep '/dbus'
  ibus-daem 3471 jamie8u unix 0x  0t0  26107 
@/tmp/ibus/dbus-SpxOl8Fc type=STREAM
  ...

  (notice '@/tmp/ibus/' in the path)

  In addition to the above, you can test for regressions by opening
  'System Settings' under the 'gear' icon in the panel and selecting
  'Text Entry'. From there, add an input source on the right, make sure
  'Show current input source in the menu bar' is checked, then use the
  input source panel indicator to change input sources.

  Extended test case to verify input support still works in unconfined
  and confined applications:

  1. Systems Settings Language Support, if prompted install the complete 
language support
  2. Install Chinese (simple and traditional)
  3. sudo apt-get install ibus-pinyin ibus-sunpinyin
  4. logout / login
  5. System Settings / Text Entry - add Chinese (Pinyin) (IBus)
  6. select pinyin from the indicator
  7. sudo lsof | grep ibus | grep @ # will use @/tmp/dbus-...
  8. open gnome-calculator and try to type something in (should get a pop-up)
  9. open evince and try to search a pdf (should get a pop up)
  10. upgrade apparmor and im-config from xenial-proposed
  11. logout and back in
  12. sudo lsof | grep ibus | grep @ # will use @/tmp/ibus/...
  13. open gnome-calculator and try to type something in (should get a pop-up)
  14. open evince and try to search a pdf (should get a pop up)
  15. verify no new apparmor denials

  [Regression Potential]

  The regression potential is considered low because there are no
  compiled code changes and because the changes only occur after ibus-
  daemon is restarted, which is upon session start, not package upgrade.
  When it is restarted, the files in ~/.config/ibus/bus/*-unix-0 are
  updated accordingly for other applications to pick up.

  This change intentionally requires a change to the unity7 snapd
  interface, which is in already done.

  This change intentionally requires a change to apparmor to add a unix
  rule for communicating with the new ibus address. This is in xenial-
  proposed 2.10.95-0ubuntu2.3 (and 2.10.95-0ubuntu2.4). The packages
  changes to im-config use 'Breaks: apparmor (<< 2.10.95-0ubuntu2.3) to
  ensure that the apparmor abstraction is updated and policy recompiled
  before ibus is restarted. This was omitted from the initial im-config
  upload which resulted in bug #1588197. Test cases ensuring this 

[Touch-packages] [Bug 1751677] Re: apparmor fails to start

2020-07-11 Thread Jamie Strandboge
** Project changed: apparmor => apparmor (Ubuntu)

** Changed in: apparmor (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1751677

Title:
  apparmor fails to start

Status in apparmor package in Ubuntu:
  Invalid

Bug description:
  acer@acer-Aspire-F5-573G:~$ systemctl status apparmor.service
  ● apparmor.service - AppArmor initialization
 Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor 
preset:
 Active: failed (Result: exit-code) since Mon 2018-02-26 07:32:58 +07; 9min 
ag
   Docs: man:apparmor(7)
 http://wiki.apparmor.net/
Process: 352 ExecStart=/etc/init.d/apparmor start (code=exited, status=123)
   Main PID: 352 (code=exited, status=123)

  Feb 26 07:32:57 acer-Aspire-F5-573G apparmor[352]: Skipping profile in 
/etc/appa
  Feb 26 07:32:57 acer-Aspire-F5-573G apparmor[352]: Skipping profile in 
/etc/appa
  Feb 26 07:32:57 acer-Aspire-F5-573G apparmor[352]: AppArmor parser error for 
/et
  Feb 26 07:32:57 acer-Aspire-F5-573G apparmor[352]: AppArmor parser error for 
/et
  Feb 26 07:32:57 acer-Aspire-F5-573G apparmor[352]: Skipping profile in 
/etc/appa
  Feb 26 07:32:58 acer-Aspire-F5-573G apparmor[352]:...fail!
  Feb 26 07:32:58 acer-Aspire-F5-573G systemd[1]: apparmor.service: Main 
process e
  Feb 26 07:32:58 acer-Aspire-F5-573G systemd[1]: Failed to start AppArmor 
initial
  Feb 26 07:32:58 acer-Aspire-F5-573G systemd[1]: apparmor.service: Unit 
entered f
  Feb 26 07:32:58 acer-Aspire-F5-573G systemd[1]: apparmor.service: Failed with 
re

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1751677/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1886115] Re: libseccomp 2.4.3-1ubuntu3.18.04.2 causes systemd to segfault on boot

2020-07-07 Thread Jamie Strandboge
This seems related:
* https://bugzilla.redhat.com/show_bug.cgi?id=1653068
* https://github.com/systemd/systemd/pull/11157

I can't say why the libseccomp update would change anything, though the
redhat bug shows an AVC denial, so I wonder if you see anything related
to systemd-resolved with 'journalctl | grep audit | grep systemd' at the
time of the boot failure. If you see a seccomp denial, that might
indicate a change in libseccomp to further investigate.

Regardless, systemd should not be crashing and
https://github.com/systemd/systemd/pull/11157 should be backported IME.

** Bug watch added: Red Hat Bugzilla #1653068
   https://bugzilla.redhat.com/show_bug.cgi?id=1653068

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1886115

Title:
  libseccomp 2.4.3-1ubuntu3.18.04.2 causes systemd to segfault on boot

Status in libseccomp package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
After applying updates to Ubuntu 18.04 my desktop (apple mini with
  i5-2415M CPU) failed to complete the boot process.  A few seconds into
  the boot, the last message displayed is "/var mounted".  The system
  then appears to hang indefinitely.

Luckily, the 'rescue' boot image allows the boot process to proceed 
sufficiently far to allow a root shell to be spawned.  Unfortunately no log 
files were written during the unsuccessful attempts to boot.  Spawning a 2nd 
root shell (# nohup getty tty5) on a 2nd virtual terminal (tty5) I was able to 
observe the message 'systemd freezing execution' after I closed the first root 
shell and resumed the boot process.  Further a core file was created (belonging 
to /sbin/init) in the root fs
  --8<--
  (gdb) bt
  #0  0x7f16807ba187 in kill () at ../sysdeps/unix/syscall-template.S:78
  #1  0x563b957223b7 in ?? ()
  #2  
  #3  __GI___libc_free (mem=0x4a60d140dfd9a5) at malloc.c:3103
  #4  0x563b9577c22e in ?? ()
  #5  0x563b957672d6 in ?? ()
  #6  0x563b9576ba22 in ?? ()
  #7  0x563b9574f51a in ?? ()
  #8  0x7f16803a509a in ?? () from /lib/systemd/libsystemd-shared-237.so
  #9  0x7f16803a53ea in sd_event_dispatch () from 
/lib/systemd/libsystemd-shared-237.so
  #10 0x7f16803a5579 in sd_event_run () from 
/lib/systemd/libsystemd-shared-237.so
  #11 0x563b9572a49d in ?? ()
  #12 0x563b9571560c in ?? ()
  #13 0x7f168079cb97 in __libc_start_main (main=0x563b957139c0, argc=3, 
argv=0x7ffe78153758, 
  init=, fini=, rtld_fini=, 
  stack_end=0x7ffe78153748) at ../csu/libc-start.c:310
  #14 0x563b957164fa in ?? ()
  (gdb) 
  -->8--
   and the kernel message buffer lists 
  --8<--
  traps: systemd[1] general protection fault ip:7f17ebf6e98d sp:7ffd774d6020 
error:0 in libc-2.27.so[7f17ebed7000+1e7000]
  -->8--
  . 

To me that looked a bit like Bug 669702 of Gentoo
  (https://bugs.gentoo.org/669702) and indeed one of the (few) updates
  applied just prior the reboot was the update of libseccomp.

I was able to circumvent the problem by disabling (commenting out) the 
syscall filtering requested by systemd (on my system, only 
/etc/systemd/system/dbus-org.freedesktop.resolve1.service needed to be 
modified).
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.15
  Architecture: amd64
  CurrentDesktop: MATE
  DistroRelease: Ubuntu 18.04
  InstallationDate: Installed on 2019-03-30 (460 days ago)
  InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  MachineType: Apple Inc. Macmini5,1
  NonfreeKernelModules: wl
  Package: systemd 237-3ubuntu10.41 [modified: 
lib/systemd/system/systemd-resolved.service]
  PackageArchitecture: amd64
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.3.0-62-generic 
root=UUID=891c2e06-2b40-4e79-a57f-6e550be932bb ro recovery nomodeset
  ProcVersionSignature: Ubuntu 5.3.0-62.56~18.04.1-generic 5.3.18
  Tags:  bionic
  Uname: Linux 5.3.0-62-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dialout dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True
  dmi.bios.date: 01/24/2012
  dmi.bios.vendor: Apple Inc.
  dmi.bios.version: MM51.88Z.0077.B10.1201241549
  dmi.board.asset.tag: Base Board Asset Tag#
  dmi.board.name: Mac-8ED6AF5B48C039E1
  dmi.board.vendor: Apple Inc.
  dmi.board.version: Macmini5,1
  dmi.chassis.type: 16
  dmi.chassis.vendor: Apple Inc.
  dmi.chassis.version: Mac-8ED6AF5B48C039E1
  dmi.modalias: 
dmi:bvnAppleInc.:bvrMM51.88Z.0077.B10.1201241549:bd01/24/2012:svnAppleInc.:pnMacmini5,1:pvr1.0:rvnAppleInc.:rnMac-8ED6AF5B48C039E1:rvrMacmini5,1:cvnAppleInc.:ct16:cvrMac-8ED6AF5B48C039E1:
  dmi.product.family: Macmini
  dmi.product.name: Macmini5,1
  dmi.product.sku: System SKU#
  dmi.product.version: 1.0
  dmi.sys.vendor: Apple Inc.
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.15
  Architecture: amd64
  CurrentDesktop: 

[Touch-packages] [Bug 1886115] Re: libseccomp 2.4.3-1ubuntu3.18.04.2 causes systemd to segfault on boot

2020-07-07 Thread Jamie Strandboge
Note that 2.4.1-0ubuntu0.18.04.2 was previously in bionic and had been
since May of 2019 (2.3.1-2.1ubuntu4 is what bionic was released with,
but later updated to 2.4.1-0ubuntu0.18.04.2). 2.4.1-0ubuntu0.18.04.2 can
be found here:
https://launchpad.net/ubuntu/+source/libseccomp/2.4.1-0ubuntu0.18.04.2

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1886115

Title:
  libseccomp 2.4.3-1ubuntu3.18.04.2 causes systemd to segfault on boot

Status in libseccomp package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
After applying updates to Ubuntu 18.04 my desktop (apple mini with
  i5-2415M CPU) failed to complete the boot process.  A few seconds into
  the boot, the last message displayed is "/var mounted".  The system
  then appears to hang indefinitely.

Luckily, the 'rescue' boot image allows the boot process to proceed 
sufficiently far to allow a root shell to be spawned.  Unfortunately no log 
files were written during the unsuccessful attempts to boot.  Spawning a 2nd 
root shell (# nohup getty tty5) on a 2nd virtual terminal (tty5) I was able to 
observe the message 'systemd freezing execution' after I closed the first root 
shell and resumed the boot process.  Further a core file was created (belonging 
to /sbin/init) in the root fs
  --8<--
  (gdb) bt
  #0  0x7f16807ba187 in kill () at ../sysdeps/unix/syscall-template.S:78
  #1  0x563b957223b7 in ?? ()
  #2  
  #3  __GI___libc_free (mem=0x4a60d140dfd9a5) at malloc.c:3103
  #4  0x563b9577c22e in ?? ()
  #5  0x563b957672d6 in ?? ()
  #6  0x563b9576ba22 in ?? ()
  #7  0x563b9574f51a in ?? ()
  #8  0x7f16803a509a in ?? () from /lib/systemd/libsystemd-shared-237.so
  #9  0x7f16803a53ea in sd_event_dispatch () from 
/lib/systemd/libsystemd-shared-237.so
  #10 0x7f16803a5579 in sd_event_run () from 
/lib/systemd/libsystemd-shared-237.so
  #11 0x563b9572a49d in ?? ()
  #12 0x563b9571560c in ?? ()
  #13 0x7f168079cb97 in __libc_start_main (main=0x563b957139c0, argc=3, 
argv=0x7ffe78153758, 
  init=, fini=, rtld_fini=, 
  stack_end=0x7ffe78153748) at ../csu/libc-start.c:310
  #14 0x563b957164fa in ?? ()
  (gdb) 
  -->8--
   and the kernel message buffer lists 
  --8<--
  traps: systemd[1] general protection fault ip:7f17ebf6e98d sp:7ffd774d6020 
error:0 in libc-2.27.so[7f17ebed7000+1e7000]
  -->8--
  . 

To me that looked a bit like Bug 669702 of Gentoo
  (https://bugs.gentoo.org/669702) and indeed one of the (few) updates
  applied just prior the reboot was the update of libseccomp.

I was able to circumvent the problem by disabling (commenting out) the 
syscall filtering requested by systemd (on my system, only 
/etc/systemd/system/dbus-org.freedesktop.resolve1.service needed to be 
modified).
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.15
  Architecture: amd64
  CurrentDesktop: MATE
  DistroRelease: Ubuntu 18.04
  InstallationDate: Installed on 2019-03-30 (460 days ago)
  InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  MachineType: Apple Inc. Macmini5,1
  NonfreeKernelModules: wl
  Package: systemd 237-3ubuntu10.41 [modified: 
lib/systemd/system/systemd-resolved.service]
  PackageArchitecture: amd64
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.3.0-62-generic 
root=UUID=891c2e06-2b40-4e79-a57f-6e550be932bb ro recovery nomodeset
  ProcVersionSignature: Ubuntu 5.3.0-62.56~18.04.1-generic 5.3.18
  Tags:  bionic
  Uname: Linux 5.3.0-62-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dialout dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True
  dmi.bios.date: 01/24/2012
  dmi.bios.vendor: Apple Inc.
  dmi.bios.version: MM51.88Z.0077.B10.1201241549
  dmi.board.asset.tag: Base Board Asset Tag#
  dmi.board.name: Mac-8ED6AF5B48C039E1
  dmi.board.vendor: Apple Inc.
  dmi.board.version: Macmini5,1
  dmi.chassis.type: 16
  dmi.chassis.vendor: Apple Inc.
  dmi.chassis.version: Mac-8ED6AF5B48C039E1
  dmi.modalias: 
dmi:bvnAppleInc.:bvrMM51.88Z.0077.B10.1201241549:bd01/24/2012:svnAppleInc.:pnMacmini5,1:pvr1.0:rvnAppleInc.:rnMac-8ED6AF5B48C039E1:rvrMacmini5,1:cvnAppleInc.:ct16:cvrMac-8ED6AF5B48C039E1:
  dmi.product.family: Macmini
  dmi.product.name: Macmini5,1
  dmi.product.sku: System SKU#
  dmi.product.version: 1.0
  dmi.sys.vendor: Apple Inc.
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.15
  Architecture: amd64
  CurrentDesktop: MATE
  Dependencies:
   gcc-8-base 8.4.0-1ubuntu1~18.04
   libc6 2.27-3ubuntu1
   libgcc1 1:8.4.0-1ubuntu1~18.04
  DistroRelease: Ubuntu 18.04
  InstallationDate: Installed on 2019-03-30 (460 days ago)
  InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  NonfreeKernelModules: wl
  Package: libseccomp2 2.4.3-1ubuntu3.18.04.2
  PackageArchitecture: 

[Touch-packages] [Bug 1413410] Re: Unable to match embedded NULLs in unix bind rule for abstract sockets

2020-06-23 Thread Jamie Strandboge
We released UC16/xenial with a new enough apparmor (which was also
backported to trusty) so we can mark the snapd task as Invalid, which I
did just now.

** Changed in: snappy
   Status: Incomplete => Invalid

** Changed in: snappy
 Assignee: Jamie Strandboge (jdstrand) => (unassigned)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1413410

Title:
  Unable to match embedded NULLs in unix bind rule for abstract sockets

Status in AppArmor:
  Fix Released
Status in AppArmor 2.9 series:
  In Progress
Status in Snappy:
  Invalid
Status in apparmor package in Ubuntu:
  Fix Released

Bug description:
  On Ubuntu 14.10, I had this in my logs:
  Jan 21 16:32:30 localhost kernel: [24900.927939] audit: type=1400 
audit(1421879550.441:534): apparmor="DENIED" operation="bind" 
profile="/usr/lib/firefox/firefox{,*[^s][^h]}" pid=12356 comm="plugin-containe" 
family="unix" sock_type="dgram" protocol=0 requested_mask="bind" 
denied_mask="bind" 
addr="@676F6F676C652D6E61636C2D6F316431323335362D33393100"

  $ aa-decode 
676F6F676C652D6E61636C2D6F316431323335362D33393100
  Decoded: google-nacl-o1d12356-391

  $ aa-decode 676F6F676C652D6E61636C2D6
  Decoded: google-nacl-`

  So I tried the following:
  unix bind type=dgram addr=@google-nacl*,
  unix bind type=dgram addr="@google-nacl*",
  unix bind type=dgram addr=@676F6F676C652D6E61636C2D6*,
  unix bind type=dgram addr="@676F6F676C652D6E61636C2D6*",
  unix bind type=dgram addr=@google-nacl*\\000*,
  unix bind type=dgram 
addr=@google-nacl*[0-9a-zA-Z]\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000{,\\000,\\000\\000},

  
  but none of them match. The best I could do was:
  unix bind type=dgram,

  This is likely going to be important for snappy since snappy will have the 
concept of different coordinating snaps interacting via abstract sockets. What 
is interesting is that this seems to work ok for some things, eg:
  ./lightdm:  unix (bind, listen) type=stream 
addr="@/com/ubuntu/upstart-session/**",
  ./lightdm:  unix (bind, listen) type=stream addr="@/tmp/dbus-*",
  ./lightdm:  unix (bind, listen) type=stream addr="@/tmp/.ICE-unix/[0-9]*",
  ./lightdm:  unix (bind, listen) type=stream addr="@/dbus-vfs-daemon/*",
  ./lightdm:  unix (bind, listen) type=stream addr="@guest*",

  Is this something in how firefox is setting up the socket?

  To reproduce, enable the firefox profile, start firefox and try to
  attend a google hangout.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1413410/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1872106] Re: isc-dhcp-server crashing constantly [Ubuntu 20.04]

2020-06-15 Thread Jamie Strandboge
@mm - that probably isn't the issue, but you can adjust
/etc/apparmor.d/local/usr.sbin.dhcpd to have:

@{PROC}/sys/net/ipv4/ip_local_port_range r,

and then do: sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.dhcpd #
yes, without local/

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1872106

Title:
  isc-dhcp-server crashing constantly [Ubuntu 20.04]

Status in isc-dhcp package in Ubuntu:
  Confirmed

Bug description:
  isc-dhcp-server crashing constantly (sometimes within seconds or minutes, 
sometimes within hours) with the following error messages:
  Apr 10 17:45:25 xxx dhcpd[140823]: Server starting service.
  Apr 10 17:45:25 xxx sh[140823]: ../../../../lib/isc/unix/socket.c:3361: 
INSIST(!sock->pending_send) failed, back trace
  Apr 10 17:45:25 xxx sh[140823]: #0 0x7f3362f59a4a in ??
  Apr 10 17:45:25 xxx sh[140823]: #1 0x7f3362f59980 in ??
  Apr 10 17:45:25 xxx sh[140823]: #2 0x7f3362f957e1 in ??
  Apr 10 17:45:25 xxx sh[140823]: #3 0x7f3362d3c609 in ??
  Apr 10 17:45:25 xxx sh[140823]: #4 0x7f3362e78103 in ??
  Apr 10 17:45:25 xxx systemd[1]: isc-dhcp-server.service: Main process exited, 
code=killed, status=6/ABRT
  Apr 10 17:45:25 xxx systemd[1]: isc-dhcp-server.service: Failed with result 
'signal'.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1872106/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1882484] Re: Firewall rule in before.rules for dhcp is wrong

2020-06-15 Thread Jamie Strandboge
Marking as Invalid since the default firewall policy is working as
intended.

** Changed in: ufw (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1882484

Title:
  Firewall rule in before.rules for dhcp is wrong

Status in ufw package in Ubuntu:
  Invalid

Bug description:
  The file delivered - /usr/share/ufw/iptables/before.rules
  which is then copied to - /etc/ufw/before.rules

  Delivered by Package:

  # allow dhcp client to work
  -A ufw-before-input -p udp --sport 67 --dport 68 -j ACCEPT

  The ports for
  --sport and --dport are swapped

  Should be:

  -A ufw-before-input -p udp --sport 68 --dport 67 -j ACCEPT

  
  Package version found in:
0.36-0ubuntu0.1

  
  Note: ISC DHCP uses RAW sockets, which bypasses iptables anyway and doesn't 
drop the packets with the incorrect configuration. This has had me stumped for 
the last hour.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1882484/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1882484] Re: Firewall rule in before.rules for dhcp is wrong

2020-06-15 Thread Jamie Strandboge
Thank you for filing a bug.

The firewall policy is a combination of the default policy for each of
'incoming', 'outgoing' and 'routed' (forward) along with the policies
shipped in before{,6}.rules, after{,6}.rules and whatever gets added to
user{,6}.rules. Specifically, what is in before{,6}.rules is designed
with default deny for incoming (and forward), default allow for outgoing
and default accept for established connections. Considering that dhcp
uses port 68/udp for the client and port 67/udp for the server, the
shipped default policy allows:

* outgoing from this host port 68/udp to any port 67/udp (via default allow 
outgoing; eg, for dhcp request)
* incoming for established connection (via before.rules RELATED,ESTABLISHED; 
eg, dhcp reply from the server we connected to on port 67/udp)
* incoming from port 67/udp (via the before.rules you mentioned; eg, for a 
server responding to the broadcast)

I suspect that you've updated your default policy to deny to perform
egress filtering so you need to add a corresponding 'ufw allow out to
any port 67 proto udp comment "dhcp discover"' rule or similar.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1882484

Title:
  Firewall rule in before.rules for dhcp is wrong

Status in ufw package in Ubuntu:
  Invalid

Bug description:
  The file delivered - /usr/share/ufw/iptables/before.rules
  which is then copied to - /etc/ufw/before.rules

  Delivered by Package:

  # allow dhcp client to work
  -A ufw-before-input -p udp --sport 67 --dport 68 -j ACCEPT

  The ports for
  --sport and --dport are swapped

  Should be:

  -A ufw-before-input -p udp --sport 68 --dport 67 -j ACCEPT

  
  Package version found in:
0.36-0ubuntu0.1

  
  Note: ISC DHCP uses RAW sockets, which bypasses iptables anyway and doesn't 
drop the packets with the incorrect configuration. This has had me stumped for 
the last hour.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1882484/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1882314] Re: Firewall rule in before6.rules for dhcp6 is wrong

2020-06-15 Thread Jamie Strandboge
Marking as Invalid since the default firewall policy is working as
intended.

** Changed in: ufw (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1882314

Title:
  Firewall rule in before6.rules for dhcp6 is wrong

Status in ufw package in Ubuntu:
  Invalid

Bug description:
  When running DHCPv6, clients are not able get IP address.
  The firewall rule in ip6table is incorrect, and not allowing client requests 
in. The ports need to be swapped and the dst address needs to be removed, as 
it's a broadcast

  The file delivered - /usr/share/ufw/iptables/before6.rules
  which is then copied to - /etc/ufw/before6.rules

  Delivered by Package:

  # allow dhcp client to work
  -A ufw6-before-input -p udp -s fe80::/10 --sport 547 -d fe80::/10 --dport 546 
-j ACCEPT

  The ports for
  --sport and --dport are swapped
  -d fe80::/10 needs to be removed

  Should be:

  -A ufw6-before-input -p udp -s fe80::/10 --sport 546 --dport 547 -j
  ACCEPT

  Package version found in:
    0.36-0ubuntu0.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1882314/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1882314] Re: Firewall rule in before6.rules for dhcp6 is wrong

2020-06-15 Thread Jamie Strandboge
Thank you for filing a bug.

The firewall policy is a combination of the default policy for each of
'incoming', 'outgoing' and 'routed' (forward) along with the policies
shipped in before{,6}.rules, after{,6}.rules and whatever gets added to
user{,6}.rules. Specifically, what is in before{,6}.rules is designed
with default deny for incoming (and forward), default allow for outgoing
and default accept for established connections. Considering that dhcpv6
uses port 546/udp for the client and port 547/udp for the server, the
shipped default policy allows:

* outgoing from this host port 546/udp to any port 547/udp (via default allow 
outgoing; eg, for dhcp request)
* incoming for established connection (via before6.rules RELATED,ESTABLISHED; 
eg, dhcp reply from the server we connected to on port 547/udp)
* incoming from fe80::/10 port 547/udp (via the before6.rules you mentioned; 
eg, for a server responding to the broadcast)

I suspect that you've updated your default policy to deny to perform
egress filtering so you need to add a corresponding 'ufw allow out to
ff02::1:2 port 547 proto udp comment "dhcpv6 solicit"' rule or similar.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1882314

Title:
  Firewall rule in before6.rules for dhcp6 is wrong

Status in ufw package in Ubuntu:
  Invalid

Bug description:
  When running DHCPv6, clients are not able get IP address.
  The firewall rule in ip6table is incorrect, and not allowing client requests 
in. The ports need to be swapped and the dst address needs to be removed, as 
it's a broadcast

  The file delivered - /usr/share/ufw/iptables/before6.rules
  which is then copied to - /etc/ufw/before6.rules

  Delivered by Package:

  # allow dhcp client to work
  -A ufw6-before-input -p udp -s fe80::/10 --sport 547 -d fe80::/10 --dport 546 
-j ACCEPT

  The ports for
  --sport and --dport are swapped
  -d fe80::/10 needs to be removed

  Should be:

  -A ufw6-before-input -p udp -s fe80::/10 --sport 546 --dport 547 -j
  ACCEPT

  Package version found in:
    0.36-0ubuntu0.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1882314/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1876055] Re: SRU: Backport 2.4.3-1ubuntu3 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base and test suite robustness

2020-06-10 Thread Jamie Strandboge
Sorry, I reran bionic and *focal* autopkgtests and there are now no
regressions. Running eoan again.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1876055

Title:
  SRU: Backport 2.4.3-1ubuntu3 from groovy to focal/eoan/bionic/xenial
  for newer syscalls for core20 base and test suite robustness

Status in libseccomp package in Ubuntu:
  Fix Released
Status in libseccomp source package in Xenial:
  Fix Committed
Status in libseccomp source package in Bionic:
  Fix Committed
Status in libseccomp source package in Eoan:
  Fix Committed
Status in libseccomp source package in Focal:
  Fix Committed
Status in libseccomp source package in Groovy:
  Fix Released

Bug description:
  [Impact]

  The combination of snap-confine and snap-seccomp from snapd uses
  libseccomp to filter various system calls for confinement. The current
  version in eoan/bionic/xenial (2.4.1) is missing knowledge of various
  system calls for various architectures. As such this causes strange
  issues like python snaps segfaulting
  (https://github.com/snapcore/core20/issues/48) or the inadvertent
  denial of system calls which should be permitted by the base policy
  (https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal-
  arm64/17237).

  libseccomp in groovy is using the latest upstream base release (2.4.3)
  plus it includes a patch to add some missing aarch64 system calls
  (https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633).

  SRUing this version back to older stable releases allows libseccomp to
  operate correctly on all supported architectures.

  
  Included as part of this SRU are test-suite reliability improvements - 
currently the xenial libseccomp package overrides test-suite failures at build 
time to ignore failures. This masks the fact that on ppc64el and s390x there 
are currently test suite failures at build time for xenial - these failures 
occur since libseccomp now includes knowledge of system calls for these 
architectures but which the linux-libc-dev package for xenial does not actually 
define (since this is based of the 4.4 kernel in xenial whereas libseccomp 
2.4.1 in xenial has knowledge of all system calls up to 5.4). 

  In this SRU I have instead fixed the test suite failures for xenial by
  including a local (test-suite specific) set of architecture specific
  kernel headers from the linux-libc-dev in focal for all releases.
  These are just the headers which define the system call numbers for
  each architecture *and* these are added to tests/include/$ARCH in the
  source package (and tests/Makefile.am is then updated to include these
  new headers only).  As such this ensures the actual build of
  libseccomp or any of the tools does not reference these headers. This
  allows the test suite in libseccomp to then be aware of theses system
  calls and so all unit tests for all architectures now pass.

  In any future updates for libseccomp to add new system calls, we can
  then similarly update these local headers to ensure the unit tests
  continue to work as expected.

  
  [Test Case]

  libseccomp includes a significant unit test suite that is run during
  the build and as part of autopkgtests. To verify the new aarch64
  system calls are resolved as expected the scmp_sys_resolver command
  can be used as well:

  $ scmp_sys_resolver -a aarch64 getrlimit
  163

  (whereas in the current version in focal this returns -10180 as
  libseccomp was not aware of this system-call at compile-time).

  As part of this SRU, the test suite in libseccomp has been patched to
  include a local copy of the architecture-specific kernel headers from
  the 5.4 kernel in focal *for all releases*, so that all system calls
  which are defined for the 5.4 kernel are known about *for the
  libseccomp test suite*. This allows all unit tests to pass on older
  releases as well and defaults the build to fail on unit test failures
  (whereas currently in xenial this has been overridden to ignore
  failures).

  
  [Regression Potential]

  This has a low regression potential due to significant testing with
  many packages that depend on libseccomp (lxc, qemu, snapd, apt, man
  etc) and none have shown any regression using this new version. The
  re-enablement of build failure on test failure at build time also
  ensures that we can reliably detect FTBFS issues in the future.

  No symbols have been removed (or added) with this update in version so
  there is no chance of regression due to ABI change etc. In the past,
  the security team has performed more significant version upgrades for
  libseccomp (2.2, 2.3, 2.4) -> 2.4.1 without major incident. In the
  case of *this* SRU, we are only doing a micro-version upgrade from
  2.4.1 to 2.4.3 so this carries even less change of regressions.

  Any possible regressions may include applications now seeing correct
  system call 

[Touch-packages] [Bug 1876055] Re: SRU: Backport 2.4.3-1ubuntu3 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base and test suite robustness

2020-06-10 Thread Jamie Strandboge
FYI, I reran the bionic and eoan autopkgtests and there are now no
regressions.

** Tags removed: verification-needed-bionic verification-needed-eoan 
verification-needed-focal verification-needed-xenial
** Tags added: verification-done-bionic verification-done-eoan 
verification-done-focal verification-done-xenial

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1876055

Title:
  SRU: Backport 2.4.3-1ubuntu3 from groovy to focal/eoan/bionic/xenial
  for newer syscalls for core20 base and test suite robustness

Status in libseccomp package in Ubuntu:
  Fix Released
Status in libseccomp source package in Xenial:
  Fix Committed
Status in libseccomp source package in Bionic:
  Fix Committed
Status in libseccomp source package in Eoan:
  Fix Committed
Status in libseccomp source package in Focal:
  Fix Committed
Status in libseccomp source package in Groovy:
  Fix Released

Bug description:
  [Impact]

  The combination of snap-confine and snap-seccomp from snapd uses
  libseccomp to filter various system calls for confinement. The current
  version in eoan/bionic/xenial (2.4.1) is missing knowledge of various
  system calls for various architectures. As such this causes strange
  issues like python snaps segfaulting
  (https://github.com/snapcore/core20/issues/48) or the inadvertent
  denial of system calls which should be permitted by the base policy
  (https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal-
  arm64/17237).

  libseccomp in groovy is using the latest upstream base release (2.4.3)
  plus it includes a patch to add some missing aarch64 system calls
  (https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633).

  SRUing this version back to older stable releases allows libseccomp to
  operate correctly on all supported architectures.

  
  Included as part of this SRU are test-suite reliability improvements - 
currently the xenial libseccomp package overrides test-suite failures at build 
time to ignore failures. This masks the fact that on ppc64el and s390x there 
are currently test suite failures at build time for xenial - these failures 
occur since libseccomp now includes knowledge of system calls for these 
architectures but which the linux-libc-dev package for xenial does not actually 
define (since this is based of the 4.4 kernel in xenial whereas libseccomp 
2.4.1 in xenial has knowledge of all system calls up to 5.4). 

  In this SRU I have instead fixed the test suite failures for xenial by
  including a local (test-suite specific) set of architecture specific
  kernel headers from the linux-libc-dev in focal for all releases.
  These are just the headers which define the system call numbers for
  each architecture *and* these are added to tests/include/$ARCH in the
  source package (and tests/Makefile.am is then updated to include these
  new headers only).  As such this ensures the actual build of
  libseccomp or any of the tools does not reference these headers. This
  allows the test suite in libseccomp to then be aware of theses system
  calls and so all unit tests for all architectures now pass.

  In any future updates for libseccomp to add new system calls, we can
  then similarly update these local headers to ensure the unit tests
  continue to work as expected.

  
  [Test Case]

  libseccomp includes a significant unit test suite that is run during
  the build and as part of autopkgtests. To verify the new aarch64
  system calls are resolved as expected the scmp_sys_resolver command
  can be used as well:

  $ scmp_sys_resolver -a aarch64 getrlimit
  163

  (whereas in the current version in focal this returns -10180 as
  libseccomp was not aware of this system-call at compile-time).

  As part of this SRU, the test suite in libseccomp has been patched to
  include a local copy of the architecture-specific kernel headers from
  the 5.4 kernel in focal *for all releases*, so that all system calls
  which are defined for the 5.4 kernel are known about *for the
  libseccomp test suite*. This allows all unit tests to pass on older
  releases as well and defaults the build to fail on unit test failures
  (whereas currently in xenial this has been overridden to ignore
  failures).

  
  [Regression Potential]

  This has a low regression potential due to significant testing with
  many packages that depend on libseccomp (lxc, qemu, snapd, apt, man
  etc) and none have shown any regression using this new version. The
  re-enablement of build failure on test failure at build time also
  ensures that we can reliably detect FTBFS issues in the future.

  No symbols have been removed (or added) with this update in version so
  there is no chance of regression due to ABI change etc. In the past,
  the security team has performed more significant version upgrades for
  libseccomp (2.2, 2.3, 2.4) -> 2.4.1 without major incident. In the
  

[Touch-packages] [Bug 1877633] Re: libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the getrlimit syscall on arm64

2020-06-10 Thread Jamie Strandboge
FYI, I reran the bionic and eoan autopkgtests and there are now no
regressions.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1877633

Title:
  libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the
  getrlimit syscall on arm64

Status in libseccomp package in Ubuntu:
  Fix Released
Status in libseccomp source package in Focal:
  Fix Committed
Status in libseccomp source package in Groovy:
  Fix Released

Bug description:
  This was reported via the snapcraft forum[1]:

  On bionic amd64, libseccomp 2.4.1-0ubuntu0.18.04.2

  $ lsb_release -d
  Description:  Ubuntu 18.04.4 LTS
  $ scmp_sys_resolver -a aarch64 163
  getrlimit
  $ scmp_sys_resolver -a aarch64 getrlimit
  163

  focal amd64, libseccomp 2.4.3-1ubuntu1 -- *__BROKEN__*

  $ lsb_release -d
  Description:  Ubuntu 20.04 LTS
  $ scmp_sys_resolver -a aarch64 163
  UNKNOWN
  $ scmp_sys_resolver -a aarch64 getrlimit
  -10180

  [1]https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal-
  arm64/17237/8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1877633] Re: libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the getrlimit syscall on arm64

2020-06-10 Thread Jamie Strandboge
Sorry, I reran bionic and *focal* autopkgtests and there are now no
regressions. Running eoan again.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1877633

Title:
  libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the
  getrlimit syscall on arm64

Status in libseccomp package in Ubuntu:
  Fix Released
Status in libseccomp source package in Focal:
  Fix Committed
Status in libseccomp source package in Groovy:
  Fix Released

Bug description:
  This was reported via the snapcraft forum[1]:

  On bionic amd64, libseccomp 2.4.1-0ubuntu0.18.04.2

  $ lsb_release -d
  Description:  Ubuntu 18.04.4 LTS
  $ scmp_sys_resolver -a aarch64 163
  getrlimit
  $ scmp_sys_resolver -a aarch64 getrlimit
  163

  focal amd64, libseccomp 2.4.3-1ubuntu1 -- *__BROKEN__*

  $ lsb_release -d
  Description:  Ubuntu 20.04 LTS
  $ scmp_sys_resolver -a aarch64 163
  UNKNOWN
  $ scmp_sys_resolver -a aarch64 getrlimit
  -10180

  [1]https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal-
  arm64/17237/8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1861177] Re: seccomp_rule_add is very slow

2020-06-10 Thread Jamie Strandboge
There isn't a snapd task (snap-seccomp is compiled against libseccomp
but it can't influence this behavior), so unassigning Ian and marking
that task as Invalid.

** Changed in: snapd
   Status: Triaged => Invalid

** Changed in: snapd
 Assignee: Ian Johnson (anonymouse67) => (unassigned)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1861177

Title:
  seccomp_rule_add is very slow

Status in snapd:
  Invalid
Status in libseccomp package in Ubuntu:
  In Progress

Bug description:
  There is a known and patched issue with version 2.4 of libseccomp
  where certain operations have a large performance regression. This is
  causing some packages that use libseccomp such as container
  orchestration systems to occasionally time out or otherwise fail under
  certain workloads.

  Please consider porting the patch into the various Ubuntu versions
  that have version 2.4 of libseccomp and into the backports. The
  performance patch from version 2.5 (yet to be released) applies
  cleanly on top of the 2.4 branch of libseccomp.

  For more information, and for a copy of the patch (which can also be
  cherry picked from the upstream libseccomp repos) see the similar
  Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913

To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1861177/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1877633] Re: libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the getrlimit syscall on arm64

2020-06-10 Thread Jamie Strandboge
FYI, I reran the xenial autopkgtests and they now pass.

** Tags removed: verification-done-focal
** Tags added: verification-needed-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1877633

Title:
  libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the
  getrlimit syscall on arm64

Status in libseccomp package in Ubuntu:
  Fix Released
Status in libseccomp source package in Focal:
  Fix Committed
Status in libseccomp source package in Groovy:
  Fix Released

Bug description:
  This was reported via the snapcraft forum[1]:

  On bionic amd64, libseccomp 2.4.1-0ubuntu0.18.04.2

  $ lsb_release -d
  Description:  Ubuntu 18.04.4 LTS
  $ scmp_sys_resolver -a aarch64 163
  getrlimit
  $ scmp_sys_resolver -a aarch64 getrlimit
  163

  focal amd64, libseccomp 2.4.3-1ubuntu1 -- *__BROKEN__*

  $ lsb_release -d
  Description:  Ubuntu 20.04 LTS
  $ scmp_sys_resolver -a aarch64 163
  UNKNOWN
  $ scmp_sys_resolver -a aarch64 getrlimit
  -10180

  [1]https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal-
  arm64/17237/8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1876055] Re: SRU: Backport 2.4.3-1ubuntu3 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base and test suite robustness

2020-06-10 Thread Jamie Strandboge
FYI, I reran the xenial autopkgtests and there are now no regressions.

** Tags removed: verification-done-bionic verification-done-eoan 
verification-done-focal verification-done-xenial
** Tags added: verification-needed-bionic verification-needed-eoan 
verification-needed-focal verification-needed-xenial

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1876055

Title:
  SRU: Backport 2.4.3-1ubuntu3 from groovy to focal/eoan/bionic/xenial
  for newer syscalls for core20 base and test suite robustness

Status in libseccomp package in Ubuntu:
  Fix Released
Status in libseccomp source package in Xenial:
  Fix Committed
Status in libseccomp source package in Bionic:
  Fix Committed
Status in libseccomp source package in Eoan:
  Fix Committed
Status in libseccomp source package in Focal:
  Fix Committed
Status in libseccomp source package in Groovy:
  Fix Released

Bug description:
  [Impact]

  The combination of snap-confine and snap-seccomp from snapd uses
  libseccomp to filter various system calls for confinement. The current
  version in eoan/bionic/xenial (2.4.1) is missing knowledge of various
  system calls for various architectures. As such this causes strange
  issues like python snaps segfaulting
  (https://github.com/snapcore/core20/issues/48) or the inadvertent
  denial of system calls which should be permitted by the base policy
  (https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal-
  arm64/17237).

  libseccomp in groovy is using the latest upstream base release (2.4.3)
  plus it includes a patch to add some missing aarch64 system calls
  (https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633).

  SRUing this version back to older stable releases allows libseccomp to
  operate correctly on all supported architectures.

  
  Included as part of this SRU are test-suite reliability improvements - 
currently the xenial libseccomp package overrides test-suite failures at build 
time to ignore failures. This masks the fact that on ppc64el and s390x there 
are currently test suite failures at build time for xenial - these failures 
occur since libseccomp now includes knowledge of system calls for these 
architectures but which the linux-libc-dev package for xenial does not actually 
define (since this is based of the 4.4 kernel in xenial whereas libseccomp 
2.4.1 in xenial has knowledge of all system calls up to 5.4). 

  In this SRU I have instead fixed the test suite failures for xenial by
  including a local (test-suite specific) set of architecture specific
  kernel headers from the linux-libc-dev in focal for all releases.
  These are just the headers which define the system call numbers for
  each architecture *and* these are added to tests/include/$ARCH in the
  source package (and tests/Makefile.am is then updated to include these
  new headers only).  As such this ensures the actual build of
  libseccomp or any of the tools does not reference these headers. This
  allows the test suite in libseccomp to then be aware of theses system
  calls and so all unit tests for all architectures now pass.

  In any future updates for libseccomp to add new system calls, we can
  then similarly update these local headers to ensure the unit tests
  continue to work as expected.

  
  [Test Case]

  libseccomp includes a significant unit test suite that is run during
  the build and as part of autopkgtests. To verify the new aarch64
  system calls are resolved as expected the scmp_sys_resolver command
  can be used as well:

  $ scmp_sys_resolver -a aarch64 getrlimit
  163

  (whereas in the current version in focal this returns -10180 as
  libseccomp was not aware of this system-call at compile-time).

  As part of this SRU, the test suite in libseccomp has been patched to
  include a local copy of the architecture-specific kernel headers from
  the 5.4 kernel in focal *for all releases*, so that all system calls
  which are defined for the 5.4 kernel are known about *for the
  libseccomp test suite*. This allows all unit tests to pass on older
  releases as well and defaults the build to fail on unit test failures
  (whereas currently in xenial this has been overridden to ignore
  failures).

  
  [Regression Potential]

  This has a low regression potential due to significant testing with
  many packages that depend on libseccomp (lxc, qemu, snapd, apt, man
  etc) and none have shown any regression using this new version. The
  re-enablement of build failure on test failure at build time also
  ensures that we can reliably detect FTBFS issues in the future.

  No symbols have been removed (or added) with this update in version so
  there is no chance of regression due to ABI change etc. In the past,
  the security team has performed more significant version upgrades for
  libseccomp (2.2, 2.3, 2.4) -> 2.4.1 without major incident. In the
  case of 

  1   2   3   4   5   6   7   8   9   10   >