Bug 1219956

Thank you for bringing this issue to our attention.
We will schedule it in our team shortly.

This package was already reviewed a while long ago [1]. Nevertheless, since it's been 3 years, I seized the opportunity to review the changes since the last upstream release, 0.13 → 0.20 [2].

### D-Bus configuration
The service was renamed but the old name is kept for backwards-compatibility. Nothing has changed apart from the name. OK.

### Polkit configuration
Nothing substantial has changed. The policy remains the same: only active logged-in users may access the two interfaces (switch-profile and hold-profile). OK.

### D-Bus and Polkit implementation
The actual service implementation, including Polkit authorization, largely remained the same, apart from some refactoring. OK.

### systemd service
Likewise.

All in all there's no obvious problem with changes made in the last 3 years.
We can proceed with the whitelisting.

[1] https://bugzilla.suse.com/show_bug.cgi?id=1189900
[2] https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/compare/0.13...0.20?from_project_id=6840&straight=false

Can we remove the D-Bus service files for the old endpoint (net.hadess...)?

The package ships both the old and the new D-Bus service. As far as I can see, it's working perfectly fine with just the new service. On top of that, the new Polkit configuration effectively renders the old service inaccessible.

I suggest to remove the following files from the RPM:
./usr/share/dbus-1/system-services/net.hadess.PowerProfiles.service
./usr/share/dbus-1/system.d/net.hadess.PowerProfiles.conf

Thanks.

Looks like this was done a few weeks ago in https://build.opensuse.org/request/show/1148703.
Wolfgang, I think https://github.com/rpm-software-management/rpmlint/pull/1197 can go forward

(In reply to Filippo Bonazzi from comment #5)

https://github.com/openSUSE/polkit-default-privs/pull/103

Ah, I knew I had seen it, but couldn't find it when writing that comment. Thanks

On its way to Factory: https://build.opensuse.org/request/show/1161402

D-Bus whitelisting on its way to Factory:
https://build.opensuse.org/request/show/1161421
We should be done here as soon as both requests are accepted.

Hi all, this service currently fails to start with the following error message:

$ sudo bash -c 'STATE_DIRECTORY=/var/lib/power-profiles-daemon G_MESSAGES_DEBUG=all /usr/libexec/power-profiles-daemon'
> power-profiles-daemon is already running, or it cannot own its D-Bus name. Verify installation.

This is because power-profiles-daemon tries to acquire both the legacy dbus name "net.hadess.PowerProfiles" and the new name "org.freedesktop.UPower.PowerProfiles" on startup:

https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/blob/0.20/src/power-profiles-daemon.c#L988

Note that L988 installs the `name_lost_handler`. When the legacy name fails, the entire service exits with error:

https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/blob/0.20/src/power-profiles-daemon.c#L954

I'd expect that carefully removing all references to POWER_PROFILES_LEGACY_* in power-profiles-daemon.c would fix this. I haven't tested this solution though.

(In reply to Wolfgang Frisch from comment #3)
> Can we remove the D-Bus service files for the old endpoint (net.hadess...)?
> 
> The package ships both the old and the new D-Bus service. As far as I can
> see, it's working perfectly fine with just the new service. On top of that,
> the new Polkit configuration effectively renders the old service
> inaccessible.
> 
> I suggest to remove the following files from the RPM:
> ./usr/share/dbus-1/system-services/net.hadess.PowerProfiles.service
> ./usr/share/dbus-1/system.d/net.hadess.PowerProfiles.conf
> 
> Thanks.

Wolfgang,
We have had to add back the old net.hadess.* service and conf files because deleting them breaks power-profiles-daemon and prevents it from starting. See #c10 here and submit request at build.o.o: https://build.opensuse.org/request/show/1163727/changes

Could you please let us know if this will require a fresh audit review or are we good to let this through given these files existed on previous versions and were audited then?

Thanks in advance.

This is a surprising backward compatibility they have implemented there. I
don't think I've ever seen it before on D-Bus level. Sorry that this got
messed up. We will reinstate the old interface.

Both D-Bus configuration files are now in whitelisting again. Closing this as
fixed.