On Wednesday 08 December 2004 13:03, Valdis.Kletnieks(a)vt.edu wrote:
On Tue, 07 Dec 2004 11:50:27 EST, Valdis.Kletnieks(a)vt.edu said:
> I'm wondering if it would make more sense to push a patch upstream to the
> kernel-utils crew. Reading the smartd manpage in more detail, it looks
> like feeding it a '-M exec /usr/sbin/sendmail' (or building with that as
> the default) would let us only have to add sendmail_exec_t rather than
> all those.
Or that *would* work, if the smartd code didn't use popen() to actually run
it, giving us a gratuitous '/bin/sh -c'. Looks like some fairly hefty
reworking to make it do the whole pipe()/fork()/exec() thing itself.
In spite of what Colin says I think it would be good to get such a change in
smartd.
There are other benefits too. Imagine that we get a bad sector on the part of
disk that contains /bin/bash or one of the many shared objects it uses.
Bummer if this causes smartd not to do anything and this delay in
notification causes the administrator to lose other data as the hard disk
slowly dies.
Another issue is that hard disk errors are probably more likely than average
in times of high disk load. Anything that you can do to reduce the disk use
in performing an operation at such times will give a faster result. NB Linux
tends to give very long delays on file read or process execute if there is a
large write queue.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page