Yee-HAH! 'smartd' issues 70 avc's when it tries to send mail...

Russell Coker russell at coker.com.au
Mon Dec 27 14:55:37 UTC 2004


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




More information about the fedora-selinux-list mailing list