FEDORA-2015-13224 created by mjw 6 years ago for Fedora 22
stable

Fixed eu-unstrip for gcc5/binutils separate debuginfo files. Unbreak elfutils-libs ptrace attach with default-yama-scope.

How to install

sudo dnf upgrade --advisory=FEDORA-2015-13224

This update has been submitted for testing by mjw. This critical path update has not yet been approved for pushing to the stable repository. It must first reach a karma of 2, consisting of 0 positive karma from proventesters, along with 2 additional karma from the community. Or, it must spend 14 days in testing without any negative feedback

6 years ago

Taskotron: depcheck test PASSED on i386. Result log: https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/115506/steps/runtask/logs/stdio (results are informative only)

Taskotron: depcheck test PASSED on x86_64. Result log: https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/115506/steps/runtask/logs/stdio (results are informative only)

This update is currently being pushed to the Fedora 22 testing updates repository.

6 years ago

This update has been pushed to testing

6 years ago
User Icon sergiodj commented & provided feedback 6 years ago
karma

Works for me.

User Icon cserpentis commented & provided feedback 6 years ago
karma

seems to work OK

Critical path update approved

6 years ago

This update has reached the stable karma threshold and will be pushed to the stable updates repository

6 years ago

Taskotron: upgradepath test FAILED on noarch. Result log: https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/116291/steps/runtask/logs/stdio (results are informative only)

Automatic push to stable based on karma has been disabled for this update due to failure of an AutoQA test. Update submitter, please check the AutoQA test result and see if there is a valid problem to be fixed here, and fix it if so. If the failure is a mistake on AutoQA's part, you can re-enable the automatic push feature for this update if you like, or push it stable manually once it reaches the requirements under the Updates Policy.

6 years ago

The upgradepath test FAILED because the matching f23 update hasn't been approved yet: https://admin.fedoraproject.org/updates/FEDORA-2015-13063/elfutils-0.163-3.fc23 If people could test f23 and supply karma that would be appreciated. Once it goes into f23 it can also go into f22.

Taskotron: upgradepath test PASSED on noarch. Result log: https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/116319/steps/runtask/logs/stdio (results are informative only)

This update is currently being pushed to the Fedora 22 stable updates repository.

6 years ago

Taskotron: upgradepath test PASSED on noarch. Result log: https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/116360/steps/runtask/logs/stdio (results are informative only)

Taskotron: depcheck test PASSED on i386. Result log: https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/116361/steps/runtask/logs/stdio (results are informative only)

Taskotron: depcheck test PASSED on x86_64. Result log: https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/116361/steps/runtask/logs/stdio (results are informative only)

This update is currently being pushed to the Fedora 22 stable updates repository.

6 years ago

This update has been pushed to stable

6 years ago
User Icon bojan commented & provided feedback 6 years ago
karma

Got this on both machines where I updated this package: systemd-sysctl[415]: Failed to write '0' to '/proc/sys/kernel/yama/ptrace_scope': Operation not permitted. Coming from file 10-default-yama-scope.conf in /usr/lib/sysctl.d.

User Icon bojan commented & provided feedback 6 years ago
karma

SELinux denial: Aug 15 22:42:34 <machine> audit[663]: <audit-1400> avc: denied { sys_ptrace } for pid=663 comm="systemd-sysctl" capability=19 scontext=system_u:system_r:systemd_sysctl_t:s0 tcontext=system_u:system_r:systemd_sysctl_t:s0 tclass=capability permissive=0

This comes from the fact that elfutils-libs now pulls in default-yama-scope which installs /usr/lib/sysctl.d/10-default-yama-scope.conf which systemd-sysctl tries to execute. But systemd-sysctl is blocked by selinux from setting that sysctl. I assume this was only tested with selinux disabled. Hohum. Not good. With selinux enabled you can easily reproduce: $ systemctl start systemd-sysctl.service Job for systemd-sysctl.service failed. See "systemctl status systemd-sysctl.service" and "journalctl -xe" for details. $ systemctl status systemd-sysctl.service ● systemd-sysctl.service - Apply Kernel Variables Loaded: loaded (/usr/lib/systemd/system/systemd-sysctl.service; static; vendor preset: disabled) Active: failed (Result: exit-code) since Sat 2015-08-15 15:59:19 CEST; 35min ago Docs: man:systemd-sysctl.service(8) man:sysctl.d(5) Process: 728 ExecStart=/usr/lib/systemd/systemd-sysctl (code=exited, status=1/FAILURE) Main PID: 728 (code=exited, status=1/FAILURE) Aug 15 15:59:19 blokker systemd[1]: Starting Apply Kernel Variables... Aug 15 15:59:19 blokker systemd[1]: systemd-sysctl.service: main process exited, code=exited, status=1/FAILURE Aug 15 15:59:19 blokker systemd[1]: Failed to start Apply Kernel Variables. Aug 15 15:59:19 blokker systemd[1]: Unit systemd-sysctl.service entered failed state. Aug 15 15:59:19 blokker systemd[1]: systemd-sysctl.service failed. The logs also show a workaround: Aug 15 16:36:11 blokker python[2930]: SELinux is preventing /usr/lib/systemd/systemd-sysctl from using the sys_ptrace capability. * Plugin catchall (100. confidence) suggests ****** If you believe that systemd-sysctl should have the sys_ptrace capability by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep systemd-sysctl /var/log/audit/audit.log | audit2allow -M mypol

semodule -i mypol.pp That policy allows things to work again. So it would

be good to get this fixed in the selinux policy for systemd_sysctl_exec_t. But before that is fixed it might be good to comment out the setting in the default-yama-scope

Filed a bug report with a simple reproducer that doesn't require any updated package: https://bugzilla.redhat.com/show_bug.cgi?id=1253926 It is strange though. I am sure this used to work. It must be some other update that triggered this change in behavior.


Please login to add feedback.

Metadata
Type
bugfix
Karma
1
Signed
Content Type
RPM
Test Gating
Settings
Unstable by Karma
-3
Stable by Karma
disabled
Stable by Time
disabled
Dates
submitted
6 years ago
in testing
6 years ago
in stable
6 years ago
modified
6 years ago

Automated Test Results