Bug 1748997 - UPower does not start due to inability to create /var/lib/upower
Summary: UPower does not start due to inability to create /var/lib/upower
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 30
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1749575 1778886 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-09-04 16:06 UTC by Benjamin Berg
Modified: 2019-12-11 01:32 UTC (History)
10 users (show)

Fixed In Version: selinux-policy-3.14.3-53.fc30
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-12-11 01:32:13 UTC
Type: Bug


Attachments (Terms of Use)

Description Benjamin Berg 2019-09-04 16:06:02 UTC
upower does not start on rawhide:


Sep 04 15:57:24 localhost-live systemd[1]: Starting Daemon for power management...
Sep 04 15:57:24 localhost-live audit[2054]: AVC avc:  denied  { create } for  pid=2054 comm="(upowerd)" name="upower" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:devicekit_var_lib_t:s0 tclass=dir permissive=0
Sep 04 15:57:24 localhost-live systemd[2054]: upower.service: Failed to set up special execution directory in /var/lib: Permission denied
Sep 04 15:57:24 localhost-live systemd[2054]: upower.service: Failed at step STATE_DIRECTORY spawning /usr/libexec/upowerd: Permission denied
Sep 04 15:57:24 localhost-live systemd[1]: upower.service: Main process exited, code=exited, status=238/STATE_DIRECTORY
Sep 04 15:57:24 localhost-live systemd[1]: upower.service: Failed with result 'exit-code'.
Sep 04 15:57:24 localhost-live systemd[1]: Failed to start Daemon for power management.

I believe upower was changed to create the directory on demand rather than shipping it in the package.

Comment 1 Christian Kellner 2019-09-04 16:13:38 UTC
UPower 0.99.11[1] indeed changed to let systemd create /var/lib/upower[2]
I followed that change in the UPower spec and marked that dir as "%ghost"[3]

Should have thought about SELinux and file a bug myself immediately, sorry about that.

[1] https://gitlab.freedesktop.org/upower/upower/-/tags/UPOWER_0_99_11
[2] https://gitlab.freedesktop.org/upower/upower/blob/e1548bba61206a05bbc318b3d49ae24571755ac6/src/upower.service.in#L17
[2] https://src.fedoraproject.org/rpms/upower/c/8a7fe7d60ef7f8700bf8cbd6da2d324ff067fdd5?branch=master

Comment 2 Lukas Vrabec 2019-09-05 07:11:22 UTC
commit 293e262dfeb15666b0a7c6727c7059e362b9f658 (HEAD -> rawhide, origin/rawhide, origin/HEAD)
Author: Lukas Vrabec <lvrabec@redhat.com>
Date:   Thu Sep 5 09:05:36 2019 +0200

    Allow devicekit_var_lib_t dirs to be created by systemd during service
    startup. BZ(1748997)

Comment 3 Lukas Vrabec 2019-09-06 08:26:51 UTC
*** Bug 1749575 has been marked as a duplicate of this bug. ***

Comment 4 contactopublico57 2019-09-11 01:13:45 UTC
Rawhide 32 

Name         : upower
Version      : 0.99.11
Release      : 2.fc32
Architecture : x86_64

sudo /usr/libexec/upowerd executed in terminal restores panel icon and screen brightness vertical slider control on mate desktop until reboot.

Is dbus/systemd failing to start the upower.service due to root requirement? 
>>>>>>>>>>>>
systemctl status upower.service
● upower.service - Daemon for power management
   Loaded: loaded (/usr/lib/systemd/system/upower.service; disabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2019-09-10 21:42:50 ADT; 12min ago
     Docs: man:upowerd(8)
  Process: 1532 ExecStart=/usr/libexec/upowerd (code=exited, status=217/USER)
 Main PID: 1532 (code=exited, status=217/USER)
      CPU: 5ms

Sep 10 21:42:50 localhost.localdomain systemd[1]: upower.service: Service RestartSec=100ms expired,>
Sep 10 21:42:50 localhost.localdomain systemd[1]: upower.service: Scheduled restart job, restart co>
Sep 10 21:42:50 localhost.localdomain systemd[1]: Stopped Daemon for power management.
Sep 10 21:42:50 localhost.localdomain systemd[1]: upower.service: Start request repeated too quickl>
Sep 10 21:42:50 localhost.localdomain systemd[1]: upower.service: Failed with result 'exit-code'.
Sep 10 21:42:50 localhost.localdomain systemd[1]: Failed to start Daemon for power management.
>>>>>>>
systemctl --failed
  UNIT           LOAD   ACTIVE SUB    DESCRIPTION                
● upower.service loaded failed failed Daemon for power management

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

1 loaded units listed.

Comment 5 contactopublico57 2019-09-11 01:16:44 UTC
Addendum

This issue has been observed with recent Ubuntu, Debian package updates.

Comment 6 Adam Williamson 2019-11-27 17:03:51 UTC
This seems to be happening to F30 now, in openQA update tests on staging, e.g. https://openqa.stg.fedoraproject.org/tests/677283 - the test fails because upower.service didn't start, upower.service failed because of this. However, the F30 package log claims the patch is in it, the line "- Allow devicekit_var_lib_t dirs to be created by systemd during service startup. BZ(1748997)" is present in 3.14.3-46.fc30 changelog and the test VM has -52. So not sure what's going on there.

Comment 7 Adam Williamson 2019-11-27 17:15:30 UTC
so yeah, it seems that upower 0.99.11 went stable for F30 about 5 days ago, and 2 days ago the base F30 disk image for openQA update tests on staging instance was rebuilt, so at that point it would have included upower 0.99.11. From then on, this test has failed every time it's run on that disk image. On prod openQA instance the base image was last built just before upower 0.99.11 went stable, so it's still OK, but next time the disk image gets rebuilt we'll have this problem on prod too.

upower 0.99.11 went stable for Fedora 31 on 2019-11-18, the F31 disk image was also rebuilt for stg on 2019-11-25, and this test is passing on F31 updates, so it seems we don't have the bug on F31. But somehow on F30, the fix isn't working. Perhaps something changed in selinux-policy itself between F30 and F31 which means the fix for this doesn't backport successfully to F30?

Comment 8 Lukas Vrabec 2019-11-27 19:17:02 UTC
commit 536f614aff5bd7091a2ff3204a8114e8fd126223 (HEAD -> f30, origin/f30)
Author: Lukas Vrabec <lvrabec@redhat.com>
Date:   Mon Aug 5 18:18:03 2019 +0200

    Allow systemd to create and bindmount dirs.
    
    Add systemd_logind_var_lib_t to attribute systemd_mount_directory.
    Allow systemd create targets with labels part of systemd_mount_directory
    Resolves: rhbz#1734831

Comment 9 Adam Williamson 2019-11-29 21:48:28 UTC
Can you do a package build and update, Lukas? Thanks!

Comment 10 Lukas Vrabec 2019-12-02 12:18:32 UTC
Yes, sure. 

Zdenek can do that.

Comment 11 Gabriel Somlo 2019-12-03 13:30:38 UTC
*** Bug 1778886 has been marked as a duplicate of this bug. ***

Comment 12 Fedora Update System 2019-12-04 07:50:32 UTC
FEDORA-2019-e9d8868185 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-e9d8868185

Comment 13 Fedora Update System 2019-12-05 02:00:54 UTC
selinux-policy-3.14.3-53.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-e9d8868185

Comment 14 Zdenek Pytela 2019-12-05 09:00:54 UTC
Build is in progress.

Comment 15 Fedora Update System 2019-12-06 19:20:50 UTC
FEDORA-2019-e9d8868185 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-e9d8868185

Comment 16 Adam Williamson 2019-12-07 01:36:47 UTC
No longer needs to be marked as an F32 blocker as it's fixed in Rawhide.

Comment 17 Fedora Update System 2019-12-07 02:17:57 UTC
container-selinux-2.123.0-2.fc30, selinux-policy-3.14.3-53.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-e9d8868185

Comment 18 Fedora Update System 2019-12-11 01:32:13 UTC
container-selinux-2.123.0-2.fc30, selinux-policy-3.14.3-53.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.