On Wednesday 08 December 2004 13:03, Valdis.Kletnieks@xxxxxx wrote: > On Tue, 07 Dec 2004 11:50:27 EST, Valdis.Kletnieks@xxxxxx 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
