Bug 1096484 - /etc/apcupsd/powerfail creation permissions error
Summary: /etc/apcupsd/powerfail creation permissions error
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: apcupsd
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michal Hlavinka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-11 00:54 UTC by Greg
Modified: 2018-08-08 10:50 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-02-17 20:14:42 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Greg 2014-05-11 00:54:14 UTC
Description of problem:
Unable to create /etc/apcupsd/powerfail: ERR=Permission denied

Version-Release number of selected component (if applicable):
apcupsd-3.14.12-1.fc19.x86_64

How reproducible:
Very

Steps to Reproduce:
1. Adjust time or %bat to a convenient (small) value in /etc/apc/apcupsd.conf
2. Issue 'systemctl restart apcupsd.service'
2. Unplug UPS from mains
3. Wait a bit...

Actual results:
UPS is left running. I get the following mesage on the screen:
halting.
[3889.3453031] reboot: System halted
Systems fans are still spinning, etc. 

Expected results:
Powered-off UPS

Additional info:
This was a fresh install of apcupsd. No config changes.

I see one error in the events log.
$ cat /var/log/apcupsd.events 
2014-05-09 13:17:59 -0700  apcupsd 3.14.12 (29 March 2014) redhat startup succeeded
2014-05-09 13:21:35 -0700  apcupsd exiting, signal 15
2014-05-09 13:21:35 -0700  apcupsd shutdown succeeded
2014-05-09 13:57:09 -0700  apcupsd 3.14.12 (29 March 2014) redhat startup succeeded
2014-05-09 14:05:41 -0700  Power failure.
2014-05-09 14:05:47 -0700  Running on UPS batteries.
2014-05-09 14:59:40 -0700  Battery charge below low limit.
2014-05-09 14:59:40 -0700  Initiating system shutdown!
2014-05-09 14:59:40 -0700  Unable to create /etc/apcupsd/powerfail: ERR=Permission denied
2014-05-09 14:59:40 -0700  User logins prohibited
2014-05-09 14:59:40 -0700  apcupsd exiting, signal 15
2014-05-09 14:59:40 -0700  apcupsd shutdown succeeded
2014-05-09 15:14:46 -0700  apcupsd 3.14.12 (29 March 2014) redhat startup succeeded

# egrep 'May[[:space:]]+9 14:59' /var/log/messages
May  9 14:59:38 feynman dbus-daemon[613]: dbus[613]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper)
May  9 14:59:38 feynman dbus[613]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper)
May  9 14:59:38 feynman dbus-daemon[613]: dbus[613]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper'
May  9 14:59:38 feynman dbus[613]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper'
May  9 14:59:40 feynman apcupsd[678]: Battery charge below low limit.
May  9 14:59:40 feynman apcupsd[678]: Initiating system shutdown!
May  9 14:59:40 feynman apcupsd[678]: Unable to create /etc/apcupsd/powerfail: ERR=Permission denied
May  9 14:59:40 feynman apcupsd[678]: User logins prohibited
May  9 14:59:40 feynman dbus-daemon[613]: dbus[613]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper)
May  9 14:59:40 feynman dbus[613]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper)
May  9 14:59:40 feynman wall[8554]: wall: user root broadcasted 2 lines (85 chars)
May  9 14:59:40 feynman wall[8559]: wall: user root broadcasted 1 lines (54 chars)
May  9 14:59:40 feynman systemd[1]: Starting Show Plymouth Halt Screen...
May  9 14:59:40 feynman rsyslogd: [origin software="rsyslogd" swVersion="7.2.6" x-pid="612" x-info="http://www.rsyslog.com"] exiting on signal 15.

This does not look like a simple permissions problem.
$ stat -c '%A %U %G %n' /etc /etc/apcupsd/ /etc/apcupsd/*
drwxr-xr-x root root /etc
drwxr-xr-x root root /etc/apcupsd/
-rwxr-xr-x root root /etc/apcupsd/apccontrol
-rw-r--r-- root root /etc/apcupsd/apcupsd.conf
-rwxr--r-- root root /etc/apcupsd/changeme
-rwxr--r-- root root /etc/apcupsd/commfailure
-rwxr--r-- root root /etc/apcupsd/commok
-rwxr--r-- root root /etc/apcupsd/offbattery
-rwxr--r-- root root /etc/apcupsd/onbattery

But without that file, the UPS will never be commanded off.
[root@feynman usr]# cat /lib/systemd/system-shutdown/apcupsd_shutdown
#!/bin/sh

# See if this is a powerfail situation.
if [ -f /etc/apcupsd/powerfail ]; then
  echo
  echo "APCUPSD will now power off the UPS"
  echo
  /etc/apcupsd/apccontrol killpower
fi

Comment 1 Michal Hlavinka 2014-05-12 17:11:24 UTC
Could you please try to reproduce this with selinux disabled or in permissive mode? Thanks

Comment 2 Greg 2014-05-12 18:25:10 UTC
SELinux permissive mode results:
1. UPS shuts down.
2. Permissions error no longer seen in /var/log/apcupsd.events.
3. Setroubleshootd lines still (of course) appear in /var/log/messages.

Comment 3 Greg 2014-05-12 18:30:02 UTC
Forgot to mention tt the system shuts down as well.

Comment 4 Greg 2014-06-17 23:37:30 UTC
You might want to assign a severity to this.

According to man(8) apctest:

"It is recommended that battery runtime calibration be performed annually. Performing it too often shortens the lifetime of the UPS batteries."

Not that we really need a man page to tell us that completely draining batteries is A Bad Thing. My point is that while thile this bug exists, anyone with unstable power (the people most likely to install this package) is likely to be losing money on their on their UPS investment.

Barring rare summer thunderstorms, I am probably good to go until the fall storms. Others will not be so lucky, and this bug is taking money out of their pockets.

Comment 5 Greg 2014-09-14 20:39:20 UTC
Four months, either no progress or no update. As per my June comment, I was more-or-less fine until the fall storms hit. Apparently, attempting to give some indication that might be useful for triage is not a winning strategy. Storms could happen any time now. There have already been wind events, and shipping doc indicates that the current situation can bear a hardware cost.

My take is that direct financial costs induced by running Fedora rise above the level of a mere annoyance, but I have seen zero evidence of agreement from the Fedora project.

We have established that this is a SELinux issue. So, is the plan to ignore the problem until it can be closed WONTFIX as Fedora 19 reaches EOL, transfer it to the SELinux crew, who might actually have some idea of how to fix it, or what?

Comment 6 Fedora End Of Life 2015-01-09 21:21:37 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 7 Fedora End Of Life 2015-02-17 20:14:42 UTC
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


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