[Bug 2040483] Re: AppArmor denies crun sending signals to containers (stop, kill)
Thanks Neil, I'll let you handle the upstream. I think what you have in the MP is fine. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2040483 Title: AppArmor denies crun sending signals to containers (stop, kill) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/golang-github-containers-common/+bug/2040483/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2040483] Re: AppArmor denies crun sending signals to containers (stop, kill)
Sorry, I missed the conmon-podman denial. Would you mind making a PR to the upstream with your changes with issue you posted linked? I think Lucas will not have time until end of week. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2040483 Title: AppArmor denies crun sending signals to containers (stop, kill) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/golang-github-containers-common/+bug/2040483/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2040483] Re: AppArmor denies crun sending signals to containers (stop, kill)
Also, thanks for linking the podman issue. I'll try to merge patch upstream similar to moby and containerd. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2040483 Title: AppArmor denies crun sending signals to containers (stop, kill) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/golang-github-containers-common/+bug/2040483/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2040483] Re: AppArmor denies crun sending signals to containers (stop, kill)
@neil-aldur, did you forget to attach the debdiff? By restricting the signal set you also restrict what $SIG you can put to "podman kill --signal $SIG". I did not realize that there's a podman reference profile as well, but since podman doesn't try to kill the container by itself, I wonder if it makes sense to arbitrarily open a policy like this. Also, whether you changes are good or not, they diverge from the policy changes we have already merged to containerd and moby upstream. Not sure if that's a problem. Regarding your changes to the changelog entry in your MP: I based my entry on comment on a code comment from ahasenack (https://code.launchpad.net/~fun2program8/ubuntu/+source/crun/+git/crun/+merge/464233, you have to select b879 commit, it's the first code comment). I don't think we should copy the commit message into changelog entries. It's already in the patch. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2040483 Title: AppArmor denies crun sending signals to containers (stop, kill) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/golang-github-containers-common/+bug/2040483/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2040483] Re: AppArmor denies crun sending signals to containers (stop, kill)
@lucaskanashiro: This patch is for golang-github-containers-common source package. This source package produces golang-github-containers- common-dev binary package, which is just source code on filesystem. But podman binary package, which is produced from libpod source package, has golang-github-containers-common-dev in its Build-Depends. It doesn't depend on golang-github-containers-common-dev during runtime. So when golang-github-containers-common is updated, libpod should be rebuilt. Should I keep libpod as confirmed, and make a patch against libpod to make a rebuild? @neil-aldur: I'll try to reproduce. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2040483 Title: AppArmor denies crun sending signals to containers (stop, kill) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/golang-github-containers-common/+bug/2040483/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2063099] Re: Stopping container signal blocked by AppArmor on Ubuntu
@lucaskanashiro, I think you are trying top stop the container too soon after it's created. The container receives SIGTERM from docker before is sets up signal handlers, and because it's PID 1, the signal is ignored. Runc then kills it with SIGKILL after 10s. Try with sleep: root@cloudimg:~# time docker stop $(docker run --rm -d nginx) d975cb1c9c088db8ee5ce6d79c36b2931675cfb3ab244eb5effc8f605b357e5f real0m10.875s user0m0.059s sys 0m0.066s root@cloudimg:~# time docker stop $(docker run --rm -d nginx && sleep 1) bffbc7672f45fcda107371f3d95779e3a45152d03e7a220532ed94dcda4b72a6 real0m1.750s user0m0.066s sys 0m0.076s -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2063099 Title: Stopping container signal blocked by AppArmor on Ubuntu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/2063099/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2040483] Re: AppArmor denies crun sending signals to containers (stop, kill)
** Description changed: [ Impact ] * On mantic and noble, when run as root, podman cannot stop any container running in background because crun is being run with a new profile introduced in AppArmor v4.0.0 that doesn't have corresponding signal receive rule container's profile. * Without the fix, users would have to resort to figuring out container's PID 1 and killing it as root or by other privileged and unconfined process. This is a regression from basic podman functionality. * The fix adds signal receive rules for currently confined OCI runtimes in AppArmor v4.0.0 (runc and crun) to the profile used by podman. [ Test Plan ] All commands must be invoked as root. + + Run tests below with both crun and runc OCI runtimes. For crun, nothing + has to be changed (it's installed and used by default). For runc, first + install the runc pakcage, and then insert "--runtime /usr/sbin/runc" + arguments after "podman run". Start container in background and then stop it: # Run container in background (-d) podman run -d --name foo docker.io/library/nginx:latest # Stop the container podman stop foo On success, the last command should print the container name and the container running in background should be stopped (verify with "podman ps"). Additional tests: Verify that container running in foreground TTY can be stopped. # Terminal 1: # Run container on this TTY podman run -it --name bar --rm docker.io/library/ubuntu:22.04 # Terminal 2: # Stop the container podman stop bar On success, the last command should print the container name, the process running in terminal 1 should stop, and the container should be removed (verify with "podman ps -a"). Verify that container running with dumb init can be killed. # Run container in background (-d) with dumb init podman run -d --name bar --rm --init ubuntu:22.04 sleep infinity # Stop the container podman stop bar On success, the last command should print the container name and the container running in background should be stopped and removed (verify with "podman ps -a"). Verify container processes can signal each other # Run container in foreground with processes sending signals between themselves podman run ubuntu:22.04 sh -c 'sleep inf & sleep 1 ; kill $!' On success, the last command should exit after cca 1 second with exit status 0. [ Where problems could occur ] * The fix requires a rebuild of podman that will pull in any other changes in the archive since the last build, which could potentially break some functionality. [ Original report ] Mantic's system podman containers are completely broken due to bug 2040082. However, after fixing that (rebuilding with the patch, or a *shht don't try this at home* hack [1]), the AppArmor policy still causes bugs: podman run -it --rm docker.io/busybox Then podman stop -l fails with 2023-10-25T11:06:33.873998Z: send signal to pidfd: Permission denied and journal shows audit: type=1400 audit(1698231993.870:92): apparmor="DENIED" operation="signal" class="signal" profile="containers-default-0.50.1" pid=4713 comm="3" requested_mask="receive" denied_mask="receive" signal=term peer="/usr/bin/crun" This leaves the container in a broken state: # podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 61749260f9c4 docker.io/library/busybox:latest sh 40 seconds ago Exited (-1) 29 seconds ago confident_bouman # podman rm --all 2023-10-25T11:07:21.428701Z: send signal to pidfd: Permission denied Error: cleaning up container 61749260f9c4c96a51dc27fdd9cb8a86d80e4f2aa14eb7ed5b271791ff8008ae: removing container 61749260f9c4c96a51dc27fdd9cb8a86d80e4f2aa14eb7ed5b271791ff8008ae from runtime: `/usr/bin/crun delete --force 61749260f9c4c96a51dc27fdd9cb8a86d80e4f2aa14eb7ed5b271791ff8008ae` failed: exit status 1 audit: type=1400 audit(1698232041.422:93): apparmor="DENIED" operation="signal" class="signal" profile="containers-default-0.50.1" pid=4839 comm="3" requested_mask="receive" denied_mask="receive" signal=kill peer="/usr/bin/crun" [1] sed -i 's/~alpha2/000/' /usr/sbin/apparmor_parser Ubuntu 23.10 ii apparmor4.0.0~alpha2-0ubuntu5 amd64 user-space parser utility for AppArmor ii golang-github-containers-common 0.50.1+ds1-4 all Common files for github.com/containers repositories ii podman 4.3.1+ds1-8 amd64engine to run OCI-based containers in Pods -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2040483 Title: AppArmor denies
[Bug 2040483] Re: AppArmor denies crun sending signals to containers (stop, kill)
** Description changed: [ Impact ] - * On mantic and noble, when run as root, podman cannot stop any + * On mantic and noble, when run as root, podman cannot stop any container running in background because crun is being run with a new profile introduced in AppArmor v4.0.0 that doesn't have corresponding signal receive rule container's profile. - * Without the fix, users would have to resort to figuring out + * Without the fix, users would have to resort to figuring out container's PID 1 and killing it as root or by other privileged and unconfined process. This is a regression from basic podman functionality. - * The fix adds signal receive rules for currently confined OCI runtimes + * The fix adds signal receive rules for currently confined OCI runtimes in AppArmor v4.0.0 (runc and crun) to the profile used by podman. [ Test Plan ] All commands must be invoked as root. Start container in background and then stop it: - # Run container in background (-d) - podman run -d --name foo docker.io/library/nginx:latest - # Stop the container - podman stop foo + # Run container in background (-d) + podman run -d --name foo docker.io/library/nginx:latest + # Stop the container + podman stop foo On success, the last command should print the container name and the container running in background should be stopped (verify with "podman ps"). Additional tests: Verify that container running in foreground TTY can be stopped. - # Terminal 1: - # Run container on this TTY - podman run -it --name bar --rm docker.io/library/ubuntu:22.04 + # Terminal 1: + # Run container on this TTY + podman run -it --name bar --rm docker.io/library/ubuntu:22.04 - # Terminal 2: - # Stop the container - podman stop foo + # Terminal 2: + # Stop the container + podman stop bar On success, the last command should print the container name, the process running in terminal 1 should stop, and the container should be removed (verify with "podman ps -a"). Verify that container running with dumb init can be killed. - # Run container in background (-d) with dumb init - podman run -d --name bar --rm --init ubuntu:22.04 sleep infinity - # Stop the container - podman stop foo + # Run container in background (-d) with dumb init + podman run -d --name bar --rm --init ubuntu:22.04 sleep infinity + # Stop the container + podman stop bar On success, the last command should print the container name and the container running in background should be stopped and removed (verify with "podman ps -a"). Verify container processes can signal each other - # Run container in foreground with processes sending signals between themselves - podman run ubuntu:22.04 sh -c 'sleep inf & sleep 1 ; kill $!' + # Run container in foreground with processes sending signals between themselves + podman run ubuntu:22.04 sh -c 'sleep inf & sleep 1 ; kill $!' - - On success, the last command should exit after cca 1 second with exit status 0. + On success, the last command should exit after cca 1 second with exit + status 0. [ Where problems could occur ] - * The fix requires a rebuild of podman that will pull in any other + * The fix requires a rebuild of podman that will pull in any other changes in the archive since the last build, which could potentially break some functionality. - [ Original report ] - - Mantic's system podman containers are completely broken due to bug 2040082. However, after fixing that (rebuilding with the patch, or a *shht don't try this at home* hack [1]), the AppArmor policy still causes bugs: + Mantic's system podman containers are completely broken due to bug + 2040082. However, after fixing that (rebuilding with the patch, or a + *shht don't try this at home* hack [1]), the AppArmor policy still + causes bugs: podman run -it --rm docker.io/busybox Then podman stop -l fails with 2023-10-25T11:06:33.873998Z: send signal to pidfd: Permission denied and journal shows audit: type=1400 audit(1698231993.870:92): apparmor="DENIED" operation="signal" class="signal" profile="containers-default-0.50.1" pid=4713 comm="3" requested_mask="receive" denied_mask="receive" signal=term peer="/usr/bin/crun" This leaves the container in a broken state: # podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 61749260f9c4 docker.io/library/busybox:latest sh 40 seconds ago Exited (-1) 29 seconds ago confident_bouman # podman rm --all 2023-10-25T11:07:21.428701Z: send signal to pidfd: Permission denied Error: cleaning up container 61749260f9c4c96a51dc27fdd9cb8a86d80e4f2aa14eb7ed5b271791ff8008ae: removing container 61749260f9c4c96a51dc27fdd9cb8a86d80e4f2aa14eb7ed5b271791ff8008ae from runtime:
[Bug 2040483] Re: AppArmor denies crun sending signals to containers (stop, kill)
** Description changed: - Mantic's system podman containers are completely broken due to bug - 2040082. However, after fixing that (rebuilding with the patch, or a - *shht don't try this at home* hack [1]), the AppArmor policy still - causes bugs: + [ Impact ] + + * On mantic and noble, when run as root, podman cannot stop any + container running in background because crun is being run with a new + profile introduced in AppArmor v4.0.0 that doesn't have corresponding + signal receive rule container's profile. + + * Without the fix, users would have to resort to figuring out + container's PID 1 and killing it as root or by other privileged and + unconfined process. This is a regression from basic podman + functionality. + + * The fix adds signal receive rules for currently confined OCI runtimes + in AppArmor v4.0.0 (runc and crun) to the profile used by podman. + + [ Test Plan ] + + All commands must be invoked as root. + + Start container in background and then stop it: + + # Run container in background (-d) + podman run -d --name foo docker.io/library/nginx:latest + # Stop the container + podman stop foo + + On success, the last command should print the container name and the + container running in background should be stopped (verify with "podman + ps"). + + Additional tests: + + Verify that container running in foreground TTY can be stopped. + + # Terminal 1: + # Run container on this TTY + podman run -it --name bar --rm docker.io/library/ubuntu:22.04 + + # Terminal 2: + # Stop the container + podman stop foo + + On success, the last command should print the container name, the + process running in terminal 1 should stop, and the container should be + removed (verify with "podman ps -a"). + + Verify that container running with dumb init can be killed. + + # Run container in background (-d) with dumb init + podman run -d --name bar --rm --init ubuntu:22.04 sleep infinity + # Stop the container + podman stop foo + + On success, the last command should print the container name and the + container running in background should be stopped and removed (verify + with "podman ps -a"). + + Verify container processes can signal each other + + # Run container in foreground with processes sending signals between themselves + podman run ubuntu:22.04 sh -c 'sleep inf & sleep 1 ; kill $!' + + + On success, the last command should exit after cca 1 second with exit status 0. + + [ Where problems could occur ] + + * The fix requires a rebuild of podman that will pull in any other + changes in the archive since the last build, which could potentially + break some functionality. + + + [ Original report ] + + + Mantic's system podman containers are completely broken due to bug 2040082. However, after fixing that (rebuilding with the patch, or a *shht don't try this at home* hack [1]), the AppArmor policy still causes bugs: podman run -it --rm docker.io/busybox Then podman stop -l fails with 2023-10-25T11:06:33.873998Z: send signal to pidfd: Permission denied and journal shows audit: type=1400 audit(1698231993.870:92): apparmor="DENIED" operation="signal" class="signal" profile="containers-default-0.50.1" pid=4713 comm="3" requested_mask="receive" denied_mask="receive" signal=term peer="/usr/bin/crun" This leaves the container in a broken state: # podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 61749260f9c4 docker.io/library/busybox:latest sh 40 seconds ago Exited (-1) 29 seconds ago confident_bouman # podman rm --all 2023-10-25T11:07:21.428701Z: send signal to pidfd: Permission denied Error: cleaning up container 61749260f9c4c96a51dc27fdd9cb8a86d80e4f2aa14eb7ed5b271791ff8008ae: removing container 61749260f9c4c96a51dc27fdd9cb8a86d80e4f2aa14eb7ed5b271791ff8008ae from runtime: `/usr/bin/crun delete --force 61749260f9c4c96a51dc27fdd9cb8a86d80e4f2aa14eb7ed5b271791ff8008ae` failed: exit status 1 audit: type=1400 audit(1698232041.422:93): apparmor="DENIED" operation="signal" class="signal" profile="containers-default-0.50.1" pid=4839 comm="3" requested_mask="receive" denied_mask="receive" signal=kill peer="/usr/bin/crun" [1] sed -i 's/~alpha2/000/' /usr/sbin/apparmor_parser Ubuntu 23.10 ii apparmor4.0.0~alpha2-0ubuntu5 amd64 user-space parser utility for AppArmor ii golang-github-containers-common 0.50.1+ds1-4 all Common files for github.com/containers repositories ii podman 4.3.1+ds1-8 amd64engine to run OCI-based containers in Pods -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2040483 Title: AppArmor denies crun sending signals to
[Bug 2040483] Re: AppArmor denies crun sending signals to containers (stop, kill)
** Merge proposal linked: https://code.launchpad.net/~virtustom/ubuntu/+source/golang-github-containers-common/+git/golang-github-containers-common/+merge/465117 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2040483 Title: AppArmor denies crun sending signals to containers (stop, kill) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/golang-github-containers-common/+bug/2040483/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2040483] Re: AppArmor denies crun sending signals to containers (stop, kill)
** Also affects: golang-github-containers-common (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2040483 Title: AppArmor denies crun sending signals to containers (stop, kill) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/golang-github-containers-common/+bug/2040483/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2063099] Re: Stopping container signal blocked by AppArmor on Ubuntu
I'll copy the workaround I mentioned in #2039294 here: As a temporary workaround, put the file I have attached to /etc/apparmor.d/docker-default and load it with "apparmor_parser -Kr /etc/apparmor.d/docker-default". It will make dockerd skip loading its builtin profile as docker-default. It will also stick across reboots. The only difference between the builtin profile and the attached one are the following rules: # runc may send signals to container processes signal (receive) peer=runc, Add similar line for crun if you're using crun. ** Attachment added: "docker-default" https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/2063099/+attachment/5770044/+files/docker-default -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2063099 Title: Stopping container signal blocked by AppArmor on Ubuntu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/2063099/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2063099] Re: Stopping container signal blocked by AppArmor on Ubuntu
There's a fix proposed to upstream: https://github.com/moby/moby/pull/47749 The commit message describes the cause. These bugs have the same cause: - https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2039294 - https://bugs.launchpad.net/ubuntu/+source/libpod/+bug/2040483 The latter doesn't have a fix submitted yet. I'm working on that. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2063099 Title: Stopping container signal blocked by AppArmor on Ubuntu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/2063099/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2040483] Re: AppArmor denies crun sending signals to containers (stop, kill)
There's a similar issue with runc (and containerd and docker) reported here https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2039294 I've opened PRs with a fix upstream: - https://github.com/containerd/containerd/pull/10123 - https://github.com/moby/moby/pull/47749 I think I'll need to work a little bit more on them to dynamically add rules only for profiles that exist on the system, even though it works even if they don't exist. Is this a proper way to fix it? I have gained all my experience with AppArmor in last 2 days. For podman a similar change should be applied to the profile template defined here https://github.com/containers/common/blob/main/pkg/apparmor/apparmor_linux_template.go. I can do that later. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2040483 Title: AppArmor denies crun sending signals to containers (stop, kill) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libpod/+bug/2040483/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2039294] Re: apparmor docker
Forgot to attach the profile. Attached here. ** Attachment added: "docker-default" https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2039294/+attachment/5769855/+files/docker-default -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2039294 Title: apparmor docker To manage notifications about this bug go to: https://bugs.launchpad.net/docker/+bug/2039294/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2039294] Re: apparmor docker
As a temporary workaround, put the file I have attached to /etc/apparmor.d/docker-default and load it with "apparmor_parser -Kr /etc/apparmor.d/docker-default". This will make dockerd skip loading its builtin profile and use this one instead. The only difference between the builtin one and this one is the following rule: # runc may send signals to container processes signal (receive) peer=runc, I've opened PRs upstream: - https://github.com/containerd/containerd/pull/10123 - https://github.com/moby/moby/pull/47749 I think I'll need to work a little bit more on them to add rules only for profiles that exist. (It works even if they don't exist though.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2039294 Title: apparmor docker To manage notifications about this bug go to: https://bugs.launchpad.net/docker/+bug/2039294/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1977710] [NEW] /etc/adduser.conf.dpkg-save created by postinst since 3.121ubuntu1
Public bug reported: Since version 3.121ubuntu1 adduser's postinst script creates /etc/adduser.conf.dpkg-save file on debootstrap's root filesystem, that is, even when /etc/adduser.conf doesn't exist prior to package installation. Because of the change below the postinst script changes packaged /etc/adduser.conf and creates /etc/adduser.conf.dpkg-save as a backup: - Enable private home directories by default (LP: #48734) + Set DIR_MODE=0750 in the default adduser.conf + Change the description and default value to select private home directories by default in debconf template + Change the DIR_MODE when private home directories is configured via debconf from 0751 to 0750 to ensure files are truly private The .dpkg-save file shouldn't be present on debootstrapped system. ** Affects: adduser (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1977710 Title: /etc/adduser.conf.dpkg-save created by postinst since 3.121ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/1977710/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1406483] Re: Possible to install (and trigger postinstall) of ca-certificates-java before Java has been installed
Understood. Submitted new one: https://bugs.launchpad.net/ubuntu/+source/ca-certificates- java/+bug/1953121 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1406483 Title: Possible to install (and trigger postinstall) of ca-certificates-java before Java has been installed To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1406483/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1953121] [NEW] jks-keystore hook fails with "java: not found" during package install
Public bug reported: This is a fresh report of https://bugs.launchpad.net/ubuntu/+source/ca- certificates-java/+bug/1406483 with same steps to reproduce. Currently it can be reproduced in both impish and jammy. ca-certificates-java installs /etc/ca-certificates/update.d/jks-keystore that's being run as part of package installation. The hook is run before update-alternatives installs /usr/bin/java. The script modifies its own PATH by looking for known JRE (or JDK) installs in /usr/lib/jvm. However, the list of known JREs is hardcoded and outdated. When ca- certificatges-java is installed as a dependency of openjdk-17-jre- headless, no known JRE is found, and PATH is unchanged, so there's no java in PATH when this is first JRE being installed on the system. The fix in linked bug synced from Debian just adds paths of newer JREs to check. Currently paths up to Java 11 are checked. This issue will keep resurfacing unless ca-certificates-java is kept up to date with latest JRE in archives, or the search for JRE is changed. Steps to reproduce in official Docker jammy image (where no JRE is installed): $ sudo docker run ubuntu:impish bash -c 'apt-get update && apt-get install -y openjdk-17-jre-headless' ** Affects: ca-certificates-java (Ubuntu) Importance: Undecided Status: New ** Tags: impish jammy ** Description changed: This is a fresh report of https://bugs.launchpad.net/ubuntu/+source/ca- certificates-java/+bug/1406483 with same steps to reproduce. Currently it can be reproduced in both impish and jammy. ca-certificates-java installs /etc/ca-certificates/update.d/jks-keystore that's being run as part of package installation. The hook is run before update-alternatives installs /usr/bin/java. The script modifies its own PATH by looking for known JRE (or JDK) installs in /usr/lib/jvm. However, the list of known JREs is hardcoded and outdated. When ca- certificatges-java is installed as a dependency of openjdk-17-jre- headless, no known JRE is found, and PATH is unchanged, so there's no java in PATH when this is first JRE being installed on the system. - The fix in linked bug synced from Debian just paths of newer JREs to - check. Currently paths up to Java 11 are checked. This issue will keep - resurfacing unless ca-certificates-java is kept up to date with latest - JRE in archives, or the search for JRE is changed. + The fix in linked bug synced from Debian just adds paths of newer JREs + to check. Currently paths up to Java 11 are checked. This issue will + keep resurfacing unless ca-certificates-java is kept up to date with + latest JRE in archives, or the search for JRE is changed. Steps to reproduce in official Docker jammy image (where no JRE is installed): $ sudo docker run ubuntu:impish bash -c 'apt-get update && apt-get install -y openjdk-17-jre-headless' -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1953121 Title: jks-keystore hook fails with "java: not found" during package install To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1953121/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1406483] Re: Possible to install (and trigger postinstall) of ca-certificates-java before Java has been installed
The fix synced from Debian checks for JDK (or JRE) directories under /usr/lib/jvm and updates PATH with first found JRE. But it only checks hardcoded paths with java version up to Java 9. On Impish, ca- certificates-java package version is 20190909 and it is checks up to java version 11. So when installing first JDK/JRE newer than 11 the bug can be reproduced. Could you please reopen this bug? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1406483 Title: Possible to install (and trigger postinstall) of ca-certificates-java before Java has been installed To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1406483/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1838070] Re: Unable to add dyndbg to command line
This is not correct. The advice applies only to enabling debug messages in modules, but how does one enable debug messages kernel image? For example one could want to see debug messages from kernel/module.c which is not in any module, and the kernel parameter would be: dyndbg="file kernel/module.c +p" but grub turns that into "dyndbg=file kernel/module.c +p" which kernel fails to parse. There are other reports on the web: http://savannah.gnu.org/bugs/?44580 https://access.redhat.com/solutions/1152603 https://lists.ozlabs.org/pipermail/petitboot/2016-September/000477.html ** Bug watch added: GNU Savannah Bug Tracker #44580 http://savannah.gnu.org/bugs/?44580 ** Changed in: grub2 (Ubuntu) Status: Invalid => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1838070 Title: Unable to add dyndbg to command line To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1838070/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1943049] Re: Docker ubuntu:impish: Problem executing scripts DPkg::Post-Invoke 'rm -f /var/cache/apt/archives/*.deb /var/cache/apt/archives/partial/*.deb /var/cache/apt/*.bin || true'
Successfully tested docker.io on hirsute. With docker.io 20.10.7-0ubuntu1~21.04.2 from hirsute: $ sudo docker run ubuntu:impish apt-get remove - --allow-remove-essential e2fsprogs (Reading database ... 4386 files and directories currently installed.) Removing e2fsprogs (1.46.3-1ubuntu3) ... E: Problem executing scripts DPkg::Post-Invoke 'rm -f /var/cache/apt/archives/*.deb /var/cache/apt/archives/partial/*.deb /var/cache/apt/*.bin || true' E: Sub-process returned an error code $ echo $? 100 With docker.io 20.10.7-0ubuntu4~21.04.1 from hirsute-proposed: $ sudo docker run ubuntu:impish apt-get remove - --allow-remove-essential e2fsprogs (Reading database ... 4386 files and directories currently installed.) Removing e2fsprogs (1.46.3-1ubuntu3) ... $ echo $? 0 ** Tags removed: verification-needed-hirsute ** Tags added: verification-done-hirsute -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1943049 Title: Docker ubuntu:impish: Problem executing scripts DPkg::Post-Invoke 'rm -f /var/cache/apt/archives/*.deb /var/cache/apt/archives/partial/*.deb /var/cache/apt/*.bin || true' To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1943049/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
