| 2024-04-29 09:41:30 |
James Paton-Smith |
bug |
|
|
added bug |
| 2024-04-29 09:41:30 |
James Paton-Smith |
attachment added |
|
rsyslog.log https://bugs.launchpad.net/bugs/2064096/+attachment/5772453/+files/rsyslog.log |
|
| 2024-04-29 15:06:51 |
Simon Déziel |
bug |
|
|
added subscriber Simon Déziel |
| 2024-04-29 15:51:17 |
Launchpad Janitor |
rsyslog (Ubuntu): status |
New |
Confirmed |
|
| 2024-04-29 15:51:54 |
Gauthier Jolly |
affects |
rsyslog (Ubuntu) |
apparmor (Ubuntu) |
|
| 2024-04-29 15:52:48 |
Gauthier Jolly |
affects |
apparmor (Ubuntu) |
rsyslog (Ubuntu) |
|
| 2024-04-29 17:42:39 |
Georgia Garcia |
bug |
|
|
added subscriber Georgia Garcia |
| 2024-04-30 15:38:49 |
Andreas Hasenack |
bug |
|
|
added subscriber Andreas Hasenack |
| 2024-05-01 12:29:56 |
Andreas Hasenack |
bug task added |
|
sssd (Ubuntu) |
|
| 2024-05-01 12:30:10 |
Andreas Hasenack |
bug task added |
|
cups (Ubuntu) |
|
| 2024-05-01 12:30:35 |
Andreas Hasenack |
summary |
rsyslog service timeout on noble numbat |
Services fail to start in noble deployed with TPM+FDE |
|
| 2024-05-01 12:31:03 |
Andreas Hasenack |
sssd (Ubuntu): status |
New |
Confirmed |
|
| 2024-05-01 12:31:05 |
Andreas Hasenack |
cups (Ubuntu): status |
New |
Confirmed |
|
| 2024-05-01 12:36:16 |
Andreas Hasenack |
description |
This might be related to #2064088
The rsyslog service is continually timing out and restarting. If I use a service drop-in file and change the 'Type' from 'notify' to 'simple', the service starts and appears to work normally.
In the journal, I can see the attached apparmor errors. I can't make sense of them, but if it's a similar issue to #2064088, then I suspect apparmor is preventing the systemd notify function from alerting systemd that the service is up and running.
ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: rsyslog 8.2312.0-3ubuntu9
ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1
Uname: Linux 6.8.0-31-generic x86_64
ApportVersion: 2.28.1-0ubuntu2
Architecture: amd64
CasperMD5CheckMismatches: ./boot/grub/grub.cfg
CasperMD5CheckResult: fail
CurrentDesktop: ubuntu:GNOME
Date: Mon Apr 29 10:37:46 2024
ProcEnviron:
LANG=en_GB.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=<set>
SourcePackage: rsyslog
UpgradeStatus: No upgrade log present (probably fresh install) |
What's known so far:
- 24.04 desktop deployed with TPM+FDE shows this bug
- services confined with apparmor that need to access something in /run/systemd (like the notify socket) fail to do so, even if the apparmor profile is in complain mode
- only after running aa-disable <path> can the service start fine
- paths logged by the apparmor DENIED or ALLOWED messages are missing the "/run" prefix from "/run/systemd/......"
- other access in /run/systemd/ are also blocked, but the most noticeable one is the notify mechanism
- comment #2 also states that azure CVM images are also impacted
Original description follows:
This might be related to #2064088
The rsyslog service is continually timing out and restarting. If I use a service drop-in file and change the 'Type' from 'notify' to 'simple', the service starts and appears to work normally.
In the journal, I can see the attached apparmor errors. I can't make sense of them, but if it's a similar issue to #2064088, then I suspect apparmor is preventing the systemd notify function from alerting systemd that the service is up and running.
ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: rsyslog 8.2312.0-3ubuntu9
ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1
Uname: Linux 6.8.0-31-generic x86_64
ApportVersion: 2.28.1-0ubuntu2
Architecture: amd64
CasperMD5CheckMismatches: ./boot/grub/grub.cfg
CasperMD5CheckResult: fail
CurrentDesktop: ubuntu:GNOME
Date: Mon Apr 29 10:37:46 2024
ProcEnviron:
LANG=en_GB.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=<set>
SourcePackage: rsyslog
UpgradeStatus: No upgrade log present (probably fresh install) |
|
| 2024-05-01 12:36:46 |
Andreas Hasenack |
description |
What's known so far:
- 24.04 desktop deployed with TPM+FDE shows this bug
- services confined with apparmor that need to access something in /run/systemd (like the notify socket) fail to do so, even if the apparmor profile is in complain mode
- only after running aa-disable <path> can the service start fine
- paths logged by the apparmor DENIED or ALLOWED messages are missing the "/run" prefix from "/run/systemd/......"
- other access in /run/systemd/ are also blocked, but the most noticeable one is the notify mechanism
- comment #2 also states that azure CVM images are also impacted
Original description follows:
This might be related to #2064088
The rsyslog service is continually timing out and restarting. If I use a service drop-in file and change the 'Type' from 'notify' to 'simple', the service starts and appears to work normally.
In the journal, I can see the attached apparmor errors. I can't make sense of them, but if it's a similar issue to #2064088, then I suspect apparmor is preventing the systemd notify function from alerting systemd that the service is up and running.
ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: rsyslog 8.2312.0-3ubuntu9
ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1
Uname: Linux 6.8.0-31-generic x86_64
ApportVersion: 2.28.1-0ubuntu2
Architecture: amd64
CasperMD5CheckMismatches: ./boot/grub/grub.cfg
CasperMD5CheckResult: fail
CurrentDesktop: ubuntu:GNOME
Date: Mon Apr 29 10:37:46 2024
ProcEnviron:
LANG=en_GB.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=<set>
SourcePackage: rsyslog
UpgradeStatus: No upgrade log present (probably fresh install) |
What's known so far:
- 24.04 desktop deployed with TPM+FDE shows this bug
- services confined with apparmor that need to access something in /run/systemd (like the notify socket) fail to do so, even if the apparmor profile is in complain mode
- only after running aa-disable <path> can the service start fine
- paths logged by the apparmor DENIED or ALLOWED messages are missing the "/run" prefix from "/run/systemd/......"
- other access in /run/systemd/ are also blocked, but the most noticeable one is the notify mechanism
- comment #2 also states that azure CVM images are also impacted
- comment #4 has instructions on how to create such a VM locally with LXD vms
Original description follows:
This might be related to #2064088
The rsyslog service is continually timing out and restarting. If I use a service drop-in file and change the 'Type' from 'notify' to 'simple', the service starts and appears to work normally.
In the journal, I can see the attached apparmor errors. I can't make sense of them, but if it's a similar issue to #2064088, then I suspect apparmor is preventing the systemd notify function from alerting systemd that the service is up and running.
ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: rsyslog 8.2312.0-3ubuntu9
ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1
Uname: Linux 6.8.0-31-generic x86_64
ApportVersion: 2.28.1-0ubuntu2
Architecture: amd64
CasperMD5CheckMismatches: ./boot/grub/grub.cfg
CasperMD5CheckResult: fail
CurrentDesktop: ubuntu:GNOME
Date: Mon Apr 29 10:37:46 2024
ProcEnviron:
LANG=en_GB.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=<set>
SourcePackage: rsyslog
UpgradeStatus: No upgrade log present (probably fresh install) |
|
| 2024-05-01 12:39:49 |
Andreas Hasenack |
description |
What's known so far:
- 24.04 desktop deployed with TPM+FDE shows this bug
- services confined with apparmor that need to access something in /run/systemd (like the notify socket) fail to do so, even if the apparmor profile is in complain mode
- only after running aa-disable <path> can the service start fine
- paths logged by the apparmor DENIED or ALLOWED messages are missing the "/run" prefix from "/run/systemd/......"
- other access in /run/systemd/ are also blocked, but the most noticeable one is the notify mechanism
- comment #2 also states that azure CVM images are also impacted
- comment #4 has instructions on how to create such a VM locally with LXD vms
Original description follows:
This might be related to #2064088
The rsyslog service is continually timing out and restarting. If I use a service drop-in file and change the 'Type' from 'notify' to 'simple', the service starts and appears to work normally.
In the journal, I can see the attached apparmor errors. I can't make sense of them, but if it's a similar issue to #2064088, then I suspect apparmor is preventing the systemd notify function from alerting systemd that the service is up and running.
ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: rsyslog 8.2312.0-3ubuntu9
ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1
Uname: Linux 6.8.0-31-generic x86_64
ApportVersion: 2.28.1-0ubuntu2
Architecture: amd64
CasperMD5CheckMismatches: ./boot/grub/grub.cfg
CasperMD5CheckResult: fail
CurrentDesktop: ubuntu:GNOME
Date: Mon Apr 29 10:37:46 2024
ProcEnviron:
LANG=en_GB.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=<set>
SourcePackage: rsyslog
UpgradeStatus: No upgrade log present (probably fresh install) |
What's known so far:
- 24.04 desktop deployed with TPM+FDE shows this bug
- services confined with apparmor that need to access something in /run/systemd (like the notify socket) fail to do so, even if the apparmor profile is in complain mode. And the apparmor profile does already have rules to allow that access
- only after running aa-disable <path> can the service start fine
- paths logged by the apparmor DENIED or ALLOWED messages are missing the "/run" prefix from "/run/systemd/......". When we add rules to the profile using "/systemd/...." (i.e., also dropping the /run prefix), then it works
- other access in /run/systemd/ are also blocked, but the most noticeable one is the notify mechanism
- comment #2 also states that azure CVM images are also impacted
- comment #4 has instructions on how to create such a VM locally with LXD vms
Original description follows:
This might be related to #2064088
The rsyslog service is continually timing out and restarting. If I use a service drop-in file and change the 'Type' from 'notify' to 'simple', the service starts and appears to work normally.
In the journal, I can see the attached apparmor errors. I can't make sense of them, but if it's a similar issue to #2064088, then I suspect apparmor is preventing the systemd notify function from alerting systemd that the service is up and running.
ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: rsyslog 8.2312.0-3ubuntu9
ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1
Uname: Linux 6.8.0-31-generic x86_64
ApportVersion: 2.28.1-0ubuntu2
Architecture: amd64
CasperMD5CheckMismatches: ./boot/grub/grub.cfg
CasperMD5CheckResult: fail
CurrentDesktop: ubuntu:GNOME
Date: Mon Apr 29 10:37:46 2024
ProcEnviron:
LANG=en_GB.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=<set>
SourcePackage: rsyslog
UpgradeStatus: No upgrade log present (probably fresh install) |
|
| 2024-05-01 12:40:19 |
Andreas Hasenack |
description |
What's known so far:
- 24.04 desktop deployed with TPM+FDE shows this bug
- services confined with apparmor that need to access something in /run/systemd (like the notify socket) fail to do so, even if the apparmor profile is in complain mode. And the apparmor profile does already have rules to allow that access
- only after running aa-disable <path> can the service start fine
- paths logged by the apparmor DENIED or ALLOWED messages are missing the "/run" prefix from "/run/systemd/......". When we add rules to the profile using "/systemd/...." (i.e., also dropping the /run prefix), then it works
- other access in /run/systemd/ are also blocked, but the most noticeable one is the notify mechanism
- comment #2 also states that azure CVM images are also impacted
- comment #4 has instructions on how to create such a VM locally with LXD vms
Original description follows:
This might be related to #2064088
The rsyslog service is continually timing out and restarting. If I use a service drop-in file and change the 'Type' from 'notify' to 'simple', the service starts and appears to work normally.
In the journal, I can see the attached apparmor errors. I can't make sense of them, but if it's a similar issue to #2064088, then I suspect apparmor is preventing the systemd notify function from alerting systemd that the service is up and running.
ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: rsyslog 8.2312.0-3ubuntu9
ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1
Uname: Linux 6.8.0-31-generic x86_64
ApportVersion: 2.28.1-0ubuntu2
Architecture: amd64
CasperMD5CheckMismatches: ./boot/grub/grub.cfg
CasperMD5CheckResult: fail
CurrentDesktop: ubuntu:GNOME
Date: Mon Apr 29 10:37:46 2024
ProcEnviron:
LANG=en_GB.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=<set>
SourcePackage: rsyslog
UpgradeStatus: No upgrade log present (probably fresh install) |
What's known so far:
- 24.04 desktop deployed with TPM+FDE shows this bug
- services confined with apparmor that need to access something in /run/systemd (like the notify socket) fail to do so, even if the apparmor profile is in complain mode. And the apparmor profile does already have rules to allow that access
- only after running aa-disable <path> can the service start fine
- paths logged by the apparmor DENIED or ALLOWED messages are missing the "/run" prefix from "/run/systemd/......".
- When we add rules to the profile using "/systemd/...." (i.e., also dropping the /run prefix), then it works
- other access in /run/systemd/ are also blocked, but the most noticeable one is the notify mechanism
- comment #2 also states that azure CVM images are also impacted
- comment #4 has instructions on how to create such a VM locally with LXD vms
Original description follows:
This might be related to #2064088
The rsyslog service is continually timing out and restarting. If I use a service drop-in file and change the 'Type' from 'notify' to 'simple', the service starts and appears to work normally.
In the journal, I can see the attached apparmor errors. I can't make sense of them, but if it's a similar issue to #2064088, then I suspect apparmor is preventing the systemd notify function from alerting systemd that the service is up and running.
ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: rsyslog 8.2312.0-3ubuntu9
ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1
Uname: Linux 6.8.0-31-generic x86_64
ApportVersion: 2.28.1-0ubuntu2
Architecture: amd64
CasperMD5CheckMismatches: ./boot/grub/grub.cfg
CasperMD5CheckResult: fail
CurrentDesktop: ubuntu:GNOME
Date: Mon Apr 29 10:37:46 2024
ProcEnviron:
LANG=en_GB.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=<set>
SourcePackage: rsyslog
UpgradeStatus: No upgrade log present (probably fresh install) |
|
| 2024-05-02 05:43:39 |
Christian Ehrhardt |
bug task added |
|
apparmor (Ubuntu) |
|
| 2024-05-02 05:43:54 |
Christian Ehrhardt |
bug |
|
|
added subscriber John Johansen |
| 2024-05-02 08:52:59 |
James Paton-Smith |
attachment added |
|
autoinstall user-data YAML https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2064096/+attachment/5774010/+files/user-data |
|
| 2024-05-02 08:54:41 |
James Paton-Smith |
attachment added |
|
ps https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2064096/+attachment/5774011/+files/ps |
|
| 2024-05-02 12:31:12 |
Hector CAO |
bug |
|
|
added subscriber Hector CAO |
| 2024-05-02 13:41:35 |
Nick Rosbrook |
bug task added |
|
systemd (Ubuntu) |
|
| 2024-05-03 08:37:08 |
Pravesh Gaire |
bug |
|
|
added subscriber Pravesh Gaire |
| 2024-05-03 13:53:19 |
Nick Rosbrook |
systemd (Ubuntu): status |
New |
Confirmed |
|
| 2024-05-03 13:53:22 |
Nick Rosbrook |
systemd (Ubuntu): importance |
Undecided |
High |
|
| 2024-05-03 13:53:24 |
Nick Rosbrook |
systemd (Ubuntu): assignee |
|
Nick Rosbrook (enr0n) |
|
| 2024-05-06 20:06:12 |
Alfonso Sanchez-Beato |
bug |
|
|
added subscriber Alfonso Sanchez-Beato |
| 2024-05-07 13:57:07 |
Nobuto Murata |
bug |
|
|
added subscriber Nobuto Murata |
| 2024-05-17 08:26:51 |
Nick Rosbrook |
nominated for series |
|
Ubuntu Noble |
|
| 2024-05-17 08:26:51 |
Nick Rosbrook |
bug task added |
|
apparmor (Ubuntu Noble) |
|
| 2024-05-17 08:26:51 |
Nick Rosbrook |
bug task added |
|
rsyslog (Ubuntu Noble) |
|
| 2024-05-17 08:26:51 |
Nick Rosbrook |
bug task added |
|
cups (Ubuntu Noble) |
|
| 2024-05-17 08:26:51 |
Nick Rosbrook |
bug task added |
|
sssd (Ubuntu Noble) |
|
| 2024-05-17 08:26:51 |
Nick Rosbrook |
bug task added |
|
systemd (Ubuntu Noble) |
|
| 2024-05-17 08:27:19 |
Nick Rosbrook |
systemd (Ubuntu Noble): importance |
Undecided |
High |
|
| 2024-05-17 08:27:19 |
Nick Rosbrook |
systemd (Ubuntu Noble): assignee |
|
Nick Rosbrook (enr0n) |
|
| 2024-05-17 12:06:08 |
Nick Rosbrook |
description |
What's known so far:
- 24.04 desktop deployed with TPM+FDE shows this bug
- services confined with apparmor that need to access something in /run/systemd (like the notify socket) fail to do so, even if the apparmor profile is in complain mode. And the apparmor profile does already have rules to allow that access
- only after running aa-disable <path> can the service start fine
- paths logged by the apparmor DENIED or ALLOWED messages are missing the "/run" prefix from "/run/systemd/......".
- When we add rules to the profile using "/systemd/...." (i.e., also dropping the /run prefix), then it works
- other access in /run/systemd/ are also blocked, but the most noticeable one is the notify mechanism
- comment #2 also states that azure CVM images are also impacted
- comment #4 has instructions on how to create such a VM locally with LXD vms
Original description follows:
This might be related to #2064088
The rsyslog service is continually timing out and restarting. If I use a service drop-in file and change the 'Type' from 'notify' to 'simple', the service starts and appears to work normally.
In the journal, I can see the attached apparmor errors. I can't make sense of them, but if it's a similar issue to #2064088, then I suspect apparmor is preventing the systemd notify function from alerting systemd that the service is up and running.
ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: rsyslog 8.2312.0-3ubuntu9
ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1
Uname: Linux 6.8.0-31-generic x86_64
ApportVersion: 2.28.1-0ubuntu2
Architecture: amd64
CasperMD5CheckMismatches: ./boot/grub/grub.cfg
CasperMD5CheckResult: fail
CurrentDesktop: ubuntu:GNOME
Date: Mon Apr 29 10:37:46 2024
ProcEnviron:
LANG=en_GB.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=<set>
SourcePackage: rsyslog
UpgradeStatus: No upgrade log present (probably fresh install) |
[Impact]
On systems that have systemd in the initrd, after the switch root, services trying to access resources in /run (e.g. /run/systemd/notify) will get AppArmor denials. This is because as a part of the switch root, before the pivot_root(), the /run (and /proc, /sys, /dev) are "moved" with a bind mount. Hence the new /run has a different mount id, and AppArmor thinks that e.g. /run/systemd/notify is disconnected from the current mount tree.
[Test Plan]
The simplest way to test this is to use dracut on a classic Ubuntu system:
1. Create a VM running Ubuntu 24.04 LTS. The virtualization implementation is not important.
2. Install dracut, and then reboot.
$ apt install -y dracut
3. Once rebooted, verify that systemd did a switch root:
$ journalctl -b --grep "Switching root"
4. Check for rsyslog AppArmor denials:
$ dmesg | grep rsyslog
On an affected system, the denials will be present. With the patch, there should be no denials (or at least not related to accessing files in /run).
[Where problems could occur]
TODO
[Original Description]
What's known so far:
- 24.04 desktop deployed with TPM+FDE shows this bug
- services confined with apparmor that need to access something in /run/systemd (like the notify socket) fail to do so, even if the apparmor profile is in complain mode. And the apparmor profile does already have rules to allow that access
- only after running aa-disable <path> can the service start fine
- paths logged by the apparmor DENIED or ALLOWED messages are missing the "/run" prefix from "/run/systemd/......".
- When we add rules to the profile using "/systemd/...." (i.e., also dropping the /run prefix), then it works
- other access in /run/systemd/ are also blocked, but the most noticeable one is the notify mechanism
- comment #2 also states that azure CVM images are also impacted
- comment #4 has instructions on how to create such a VM locally with LXD vms
Original description follows:
This might be related to #2064088
The rsyslog service is continually timing out and restarting. If I use a service drop-in file and change the 'Type' from 'notify' to 'simple', the service starts and appears to work normally.
In the journal, I can see the attached apparmor errors. I can't make sense of them, but if it's a similar issue to #2064088, then I suspect apparmor is preventing the systemd notify function from alerting systemd that the service is up and running.
ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: rsyslog 8.2312.0-3ubuntu9
ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1
Uname: Linux 6.8.0-31-generic x86_64
ApportVersion: 2.28.1-0ubuntu2
Architecture: amd64
CasperMD5CheckMismatches: ./boot/grub/grub.cfg
CasperMD5CheckResult: fail
CurrentDesktop: ubuntu:GNOME
Date: Mon Apr 29 10:37:46 2024
ProcEnviron:
LANG=en_GB.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=<set>
SourcePackage: rsyslog
UpgradeStatus: No upgrade log present (probably fresh install) |
|
| 2024-05-17 14:14:56 |
Nick Rosbrook |
description |
[Impact]
On systems that have systemd in the initrd, after the switch root, services trying to access resources in /run (e.g. /run/systemd/notify) will get AppArmor denials. This is because as a part of the switch root, before the pivot_root(), the /run (and /proc, /sys, /dev) are "moved" with a bind mount. Hence the new /run has a different mount id, and AppArmor thinks that e.g. /run/systemd/notify is disconnected from the current mount tree.
[Test Plan]
The simplest way to test this is to use dracut on a classic Ubuntu system:
1. Create a VM running Ubuntu 24.04 LTS. The virtualization implementation is not important.
2. Install dracut, and then reboot.
$ apt install -y dracut
3. Once rebooted, verify that systemd did a switch root:
$ journalctl -b --grep "Switching root"
4. Check for rsyslog AppArmor denials:
$ dmesg | grep rsyslog
On an affected system, the denials will be present. With the patch, there should be no denials (or at least not related to accessing files in /run).
[Where problems could occur]
TODO
[Original Description]
What's known so far:
- 24.04 desktop deployed with TPM+FDE shows this bug
- services confined with apparmor that need to access something in /run/systemd (like the notify socket) fail to do so, even if the apparmor profile is in complain mode. And the apparmor profile does already have rules to allow that access
- only after running aa-disable <path> can the service start fine
- paths logged by the apparmor DENIED or ALLOWED messages are missing the "/run" prefix from "/run/systemd/......".
- When we add rules to the profile using "/systemd/...." (i.e., also dropping the /run prefix), then it works
- other access in /run/systemd/ are also blocked, but the most noticeable one is the notify mechanism
- comment #2 also states that azure CVM images are also impacted
- comment #4 has instructions on how to create such a VM locally with LXD vms
Original description follows:
This might be related to #2064088
The rsyslog service is continually timing out and restarting. If I use a service drop-in file and change the 'Type' from 'notify' to 'simple', the service starts and appears to work normally.
In the journal, I can see the attached apparmor errors. I can't make sense of them, but if it's a similar issue to #2064088, then I suspect apparmor is preventing the systemd notify function from alerting systemd that the service is up and running.
ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: rsyslog 8.2312.0-3ubuntu9
ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1
Uname: Linux 6.8.0-31-generic x86_64
ApportVersion: 2.28.1-0ubuntu2
Architecture: amd64
CasperMD5CheckMismatches: ./boot/grub/grub.cfg
CasperMD5CheckResult: fail
CurrentDesktop: ubuntu:GNOME
Date: Mon Apr 29 10:37:46 2024
ProcEnviron:
LANG=en_GB.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=<set>
SourcePackage: rsyslog
UpgradeStatus: No upgrade log present (probably fresh install) |
[Impact]
On systems that have systemd in the initrd, after the switch root, services trying to access resources in /run (e.g. /run/systemd/notify) will get AppArmor denials. This is because as a part of the switch root, before the pivot_root(), the /run (and /proc, /sys, /dev) are "moved" with a bind mount. Hence the new /run has a different mount id, and AppArmor thinks that e.g. /run/systemd/notify is disconnected from the current mount tree.
[Test Plan]
The simplest way to test this is to use dracut on a classic Ubuntu system:
1. Create a VM running Ubuntu 24.04 LTS. The virtualization implementation is not important.
2. Install dracut, and then reboot.
$ apt install -y dracut
3. Once rebooted, verify that systemd did a switch root:
$ journalctl -b --grep "Switching root"
4. Check for rsyslog AppArmor denials:
$ dmesg | grep rsyslog
On an affected system, the denials will be present. With the patch, there should be no denials (or at least not related to accessing files in /run).
[Where problems could occur]
Using MS_MOVE rather than MS_BIND for /run during the switch root means that there is a brief time where /run (in the old root) is not available for units running before the pivot_root(). So, if we were to see problems, it would likely
be related to problems with resources in /run, very close to the switch root timeframe. However, before noble, the switch root *is* done using MS_MOVE on /run (and /proc, /sys, and /dev), so have reasonable evidence that this is a safe change.
[Other information]
We only change the flags for /run because that is the filesystem that seems affected in practice. In particular, we leave /proc alone because code in systemd may use /proc between the time it is moved to the new root, but before the pivot_root(), which would be a riskier change.
[Original Description]
What's known so far:
- 24.04 desktop deployed with TPM+FDE shows this bug
- services confined with apparmor that need to access something in /run/systemd (like the notify socket) fail to do so, even if the apparmor profile is in complain mode. And the apparmor profile does already have rules to allow that access
- only after running aa-disable <path> can the service start fine
- paths logged by the apparmor DENIED or ALLOWED messages are missing the "/run" prefix from "/run/systemd/......".
- When we add rules to the profile using "/systemd/...." (i.e., also dropping the /run prefix), then it works
- other access in /run/systemd/ are also blocked, but the most noticeable one is the notify mechanism
- comment #2 also states that azure CVM images are also impacted
- comment #4 has instructions on how to create such a VM locally with LXD vms
Original description follows:
This might be related to #2064088
The rsyslog service is continually timing out and restarting. If I use a service drop-in file and change the 'Type' from 'notify' to 'simple', the service starts and appears to work normally.
In the journal, I can see the attached apparmor errors. I can't make sense of them, but if it's a similar issue to #2064088, then I suspect apparmor is preventing the systemd notify function from alerting systemd that the service is up and running.
ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: rsyslog 8.2312.0-3ubuntu9
ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1
Uname: Linux 6.8.0-31-generic x86_64
ApportVersion: 2.28.1-0ubuntu2
Architecture: amd64
CasperMD5CheckMismatches: ./boot/grub/grub.cfg
CasperMD5CheckResult: fail
CurrentDesktop: ubuntu:GNOME
Date: Mon Apr 29 10:37:46 2024
ProcEnviron:
LANG=en_GB.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=<set>
SourcePackage: rsyslog
UpgradeStatus: No upgrade log present (probably fresh install) |
|
| 2024-05-17 14:34:14 |
Nick Rosbrook |
systemd (Ubuntu Noble): status |
New |
In Progress |
|
| 2024-05-22 09:45:52 |
Łukasz Zemczak |
systemd (Ubuntu Noble): status |
In Progress |
Fix Committed |
|
| 2024-05-22 09:45:54 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2024-05-22 09:45:58 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2024-05-22 09:46:03 |
Łukasz Zemczak |
tags |
amd64 apport-bug noble wayland-session |
amd64 apport-bug noble verification-needed verification-needed-noble wayland-session |
|
| 2024-05-22 14:40:16 |
Nick Rosbrook |
tags |
amd64 apport-bug noble verification-needed verification-needed-noble wayland-session |
amd64 apport-bug noble verification-done-noble verification-needed wayland-session |
|
| 2024-05-27 09:06:28 |
Gabriel de Perthuis |
bug task added |
|
unbound (Ubuntu) |
|
| 2024-06-04 19:47:26 |
Launchpad Janitor |
systemd (Ubuntu Noble): status |
Fix Committed |
Fix Released |
|
| 2024-06-04 19:47:43 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
