Re: [Bug 381269] [NEW] NUT fails to shutdown UPS
2009/7/1 Martin Maney the solution Martin has proposed can only be considered as a temporary local fix (ie on your boxes but not for an upload) for affected users, for the reason I mentioned in the Debian bug linked. Not disagreeing, but frankly I can't see any very great value in the additional check of the flag file. Just curious: has there in fact been trouble with that? It seems to me that a bug like the current one is already more cost than the dubious benefit of double checking, but of course I've been bitten by one and not the other! :-/ you're right that the double check is too much, and only due to legacy and not enough time to make 100 % clean things (that's really a minor point). relying only on upsmon -K is sufficient, since it looks itself for the POWERDOWNFLAG existence *and* validity. the validity (magic string) test is harnessing the UPS poweroff, thus telling *securely* if we need to issue an UPS poweroff (upsdrvctl shutdown). not doing that can lead to security breach... Note that I'm preparing a Debian upload (2.4.1-4), introducing the new nut-clients packages, and fixing the above... Arnaud -- NUT fails to shutdown UPS https://bugs.launchpad.net/bugs/381269 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nut in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 381269] [NEW] NUT fails to shutdown UPS
On Thu, Jul 02, 2009 at 12:47:05PM -, Arnaud Quette wrote: you're right that the double check is too much, and only due to legacy and not enough time to make 100 % clean things (that's really a minor point). Actually, what I question is whether the content check is worth doing. But perhaps I've misunderstood what it's working with: for some reason, possibly from examining the file from the recovery shell while I was trying to figure out what was wrong, I have the impression it's just some obvious text (don't recall what at this time). So I can't see how this is could be thought to be secure. Perhaps there are plans to make it less easily spoofable down the road? relying only on upsmon -K is sufficient, since it looks itself for the POWERDOWNFLAG existence *and* validity. the validity (magic string) test is harnessing the UPS poweroff, thus telling *securely* if we need to issue an UPS poweroff (upsdrvctl shutdown). not doing that can lead to security breach... An intruder who can create a file in /etc has already compromised the system, and can do much more interesting things than forcing a UPS shutdown, yes? -- NUT fails to shutdown UPS https://bugs.launchpad.net/bugs/381269 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nut in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 381269] [NEW] NUT fails to shutdown UPS
the solution Martin has proposed can only be considered as a temporary local fix (ie on your boxes but not for an upload) for affected users, for the reason I mentioned in the Debian bug linked. Not disagreeing, but frankly I can't see any very great value in the additional check of the flag file. Just curious: has there in fact been trouble with that? It seems to me that a bug like the current one is already more cost than the dubious benefit of double checking, but of course I've been bitten by one and not the other! :-/ -- NUT fails to shutdown UPS https://bugs.launchpad.net/bugs/381269 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nut in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 381269] [NEW] NUT fails to shutdown UPS
Hey Martin and Chuck, thanks for the (double) report, Martin and to both for pinging me (hard to get back from a month of vacation!). you've guessed right about Lenny, and the fact that this doesn't affect prev. release due to the late appearance of libupsclient and the various work around it. now, this bug doesn't affect jaunty due to the move of the libdir to /lib in debian/rules ie http://packages.ubuntu.com/jaunty/i386/libupsclient1/filelist intrepid is affected though: http://packages.ubuntu.com/intrepid/i386/libupsclient1/filelist the above fix is the change planned for Lenny, and also the one that should be applied to any ubuntu release. the solution Martin has proposed can only be considered as a temporary local fix (ie on your boxes but not for an upload) for affected users, for the reason I mentioned in the Debian bug linked. cheers, Arnaud -- Linux / Unix Expert RD - Eaton - http://www.eaton.com/mgeops Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.free.fr/ -- NUT fails to shutdown UPS https://bugs.launchpad.net/bugs/381269 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nut in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 381269] [NEW] NUT fails to shutdown UPS
Public bug reported: Binary package hint: nut It's barely possible that Ubuntu isn't vulnerable to this - I discovered it, and did the actual smoke tests, on a Debian Lenny machine. The problem is that the nut init script's powerdown function relies on calling upsmon -K at a very late point, and that command fails, whcih causes the script to imagine that the kill ups file is not present. The reason for the failure is quite simple: ma...@furrr:~$ ldd /sbin/upsmon linux-vdso.so.1 = (0x745fe000) libupsclient.so.1 = /usr/lib/libupsclient.so.1 (0x7f49ec001000) libc.so.6 = /lib/libc.so.6 (0x7f49ebc8f000) /lib64/ld-linux-x86-64.so.2 (0x7f49ec207000) I think we would all have to agree that there's no real use placing an executable into /sbin when it depends on a library in /usr/lib, yes? This issue exists present in Debian Lenny and Ubuntu Interpid. It probably also affects Hardy and Gutsy, though they have a different sub- minor version number; however, Debian Etch, with nut 2.0.4, already has that in its init script. Etch is not affected by this bug because its upsmon does NOT have the /usr/lib/libupsclient.so dependency. I haven't any machines handy with Jaunty to check at this time. ** Affects: nut (Ubuntu) Importance: Undecided Status: New -- NUT fails to shutdown UPS https://bugs.launchpad.net/bugs/381269 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nut in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
