85 lines
3.4 KiB
Text
85 lines
3.4 KiB
Text
Desc: Ideas for future expansion and features
|
|
File: ideas.txt
|
|
Date: 20 October 2003
|
|
Auth: Russell Kroll <rkroll@exploits.org>
|
|
|
|
Here are some ideas that have come up over the years but haven't
|
|
been implemented yet. This may be a good place to start if you're
|
|
looking for a rainy day hacking project.
|
|
|
|
Non-network "upsmon"
|
|
====================
|
|
|
|
Some systems don't want a daemon listening to the network. This can be
|
|
for security reasons, or perhaps because the system has been squashed
|
|
down and doesn't have TCP/IP available. For these situations you could
|
|
run a driver and program that sits on top of the driver socket to do
|
|
local monitoring.
|
|
|
|
This also makes monitoring extremely easy to automate - you don't need
|
|
to worry about usernames, passwords or firewalling. Just start a driver
|
|
and drop this program on top of it.
|
|
|
|
- Parse ups.conf and open the state socket for a driver
|
|
|
|
- Send DUMPALL and enter a select loop
|
|
|
|
- Parse SETINFOs that change ups.status
|
|
|
|
- When you get OB LB, shut down
|
|
|
|
Completely unprivileged upsmon
|
|
==============================
|
|
|
|
upsmon currently retains root in a forked process so it can call the
|
|
shutdown command. The only reason it needs root on most systems is that
|
|
only privileged users can signal init or send a message on /dev/initctl.
|
|
|
|
In the case of systems running sysvinit (Slackware, others?), upsmon
|
|
could just open /dev/initctl while it has root and then drop it
|
|
completely. When it's time to shut down, fire a control structure at
|
|
init across the lingering socket and tell it to enter runlevel 0.
|
|
|
|
This has been shown to work in local tests, but it's not portable. It
|
|
could only be offered as an option for those systems which run that
|
|
flavor of init. It also needs to be tested to see what happens to
|
|
the lingering fd over time, such as when init restarts after an upgrade.
|
|
|
|
For other systems, there is always the possibility of having a suid
|
|
program which does nothing but prod init into starting a shutdown. Lock
|
|
down the group access so only upsmon's unprivileged user can access it,
|
|
and make that your SHUTDOWNCMD. Then it could drop root completely.
|
|
|
|
Chrooted upsmon
|
|
===============
|
|
|
|
upsmon could run the network monitoring part in a chroot jail if it had
|
|
a pipe to another process running outside for NOTIFY dispatches. Such a
|
|
pipe would have to be constructed extremely carefully so an attacker
|
|
could not compromise it from the jailed process.
|
|
|
|
A state machine with a tightly defined sequence could do this safely.
|
|
All it has to do is dispatch the UPS name and event type.
|
|
|
|
[start] [type] [length] <name> [stop]
|
|
|
|
Monitor program with interpreted language
|
|
=========================================
|
|
|
|
Once in awhile, I get requests for a way to shut down based on the UPS
|
|
temperature, or ambient humidity, or at a certain battery charge level,
|
|
or any number of things other than an "OB LB" status. It should be
|
|
obvious that adding a way to monitor all of that in upsmon would bloat
|
|
upsmon for all those people who really don't need anything like that.
|
|
|
|
A separate program that interprets a list of rules and uses it to
|
|
monitor the UPS equipment is the way to solve this. If you have a
|
|
condition that needs to be tested, add a rule.
|
|
|
|
Some of the tools that such a language would need include simple
|
|
greater-than/less-than testing (if battery.charge < 20), equivalence
|
|
testing (if ups.model = "SMART-UPS 700"), and some way to set and clear
|
|
timers.
|
|
|
|
Due to the expected size and limited audience for such a program, it
|
|
might have to be distributed separately.
|