On Fri, Jan 12, 2007 at 11:52:31AM +0000, Stephen Gran wrote: > This should be doable, though. I'm not really all that sure that adding > this feature buys us anything, though - see below for why.
well, at present it'd ensure clamd starts, which isn't a minor gain. > > BTW man clam(d)scan don't stress the point that such util run as user > > clamav, > > hence won't be able to access file/dirs not a+r/a+rx. > > See README.Debian, section CLAMAV-DAEMON, subsection WARNINGS. point is, imo, that that infos belong to both due error msg from program and manpage. Users try to figure out prg usage by doing 'man prog' - I've seen several people clueless on clam*scan failure when trying to implement a mail filter. The only way to use clam*scan in such situation (whitout playing with chmod) is to pipe the the doc to the scanner. Though this mode of operation isn't documented in clamdscan.1 (but there's a e.g. in clamscan.1). I'm fine with tem to run as uid clamav, and would rather keep'em that way even on 1.x, but that should be better documented in main info pages and prg error msg (see eg cdrecord(1) warnings about non suid root mode). > > So afaikt other pkgs have been / are going to be adjusted to refresh their > > dir trees under /var on (re)start. > > To be pedantically clear, people have discussed this on mailing lists, > but no consensus was formed that this is even the right thing to do, > much less that we should really begin implementing it, as far as I know. Well, I didn't follow each bit and threads, my point is, that Etch is currently broken. I see your point reg. each pkg redoing one or more FHS dirs on restart, but as things are shipped right, without doing so several prgs won't (re)start on (re)boot. Nor on upgrade. > processes will write to /tmp/, /var/run/clamav/, /var/lib/clamav/, and > /var/log/clamav/ and /dev/log. Why are we special casing /var/run/clamav/ ? here's what I have on a netinstalled and freshly apt-get updated Etch notebook: $ mount -t tmpfs tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /var/lock type tmpfs (rw,size=4m) tmpfs on /var/run type tmpfs (rw,size=4m) so everything under /var/run vanishes on reboot. > am not convinced that the current logic is correct, or that this is > something clamav should try to support. then the pkg responsible for setting up fstab/tmpfs should be sanitized, removing the insane - as it turns out - idea of putting any FSH leaf on a tmpfs. Or perhaps that pkg should take care to rebuild the tree under that leaf. Else each and every pkg that's supposed to find a dir there either fail solid or need redo the tree on start. I'm pretty fine with doing away with the tmpfs. thanks -- paolo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
