[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: issue with volatile clamav and/or freshclam

This one time, at band camp, Jari Jokinen said:
> Ondrej Zara wrote:
> > After istallation, restarting clamav-daemon/clamav-freshclam yields
> > the following:
> >
> > Starting ClamAV virus database updater: freshclam
> > /lib/lsb/init-functions: line 53: /sbin/start-stop-daemon: Permission
> > denied failed!
> I had the same issue, and found out that it was caused because my /sbin
> directory was chmoded to 700. And I think that's how it should be. Or is
> there any good reason why should I allow non-root users to execute
> binaries in my /sbin directory?

Why on earth would you do something so bizarre and expect your system to
work afterwards?  I routinely run fdisk, route, ifconfig, ip, lsmod,
modinfo and tc (just from a casual look in my /sbin) as a non-root user.
It is the way it is for a reason, and when I'm writing maintainer
scripts and init scripts for Debian, I depend on the target system being
sane.  Once you depart from that, you get to keep both pieces when it

> I fixed the issue by changing this line in the init script:
>   su "$User" -p -s /bin/sh -c ". /lib/lsb/init-functions && \
>   start_daemon -p $THEPIDFILE $DAEMON"
> to:
>   . /lib/lsb/init-functions && start_daemon -p "$THEPIDFILE" "$DAEMON"
> So, my question is: why the su command is there and is it essential?

The clamav project has a long and glorious history of disregard for
checking input before acting on it, and I think it's probably best to
make the Debian packages discard privilege as early as possible - in
this case, before starting up.
|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran@debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |

Attachment: signature.asc
Description: Digital signature

Reply to: