Hi Sebastian, On 01.05.2015 23:11, Sebastian Andrzej Siewior wrote: > On 2015-04-29 23:03:49 [+0200], Andreas Cadhalpun wrote: >>>> The options >>>> LocalSocket /var/run/clamav/clamd.ctl.change >>>> LocalSocketGroup nobody >>>> LocalSocketMode 600 > > same options > >> I just pushed a fix for this. >> It seems to work as intended, but additional testing would be nice. ;) > > now I see in /etc/systemd/system/clamav-daemon.socket.d/extend.conf: > [Socket] > ListenStream= > SocketUser=clamav > ListenStream=/var/run/clamav/clamd.ctl.change > SocketGroup=nobody > SocketMode=600
That's exactly what should be there. > and ls gives me: > ls -lah /var/run/clamav/ > total 0 > drwxr-xr-x 2 clamav clamav 80 May 1 22:59 . > drwxr-xr-x 16 root root 560 May 1 21:28 .. > srw-rw-rw- 1 clamav clamav 0 May 1 21:28 clamd.ctl > srw------- 1 root root 0 May 1 22:59 clamd.ctl.change > > which means the user & group is wrong. That's caused by the socket not being stopped before changing. Running 'systemctl stop clamav-daemon.socket' followed by 'systemctl start clamav-daemon.socket' makes it work. I just pushed a commit disabling the clamav-daemon.socket in prerm. This makes above work without manual intervention and also avoids the stale socket file. > The debian/clamav-daemon.postinst.in file adds ListenStream twice, so > the first (empty) one may leave. After that change I still don't see > systemd setting the permissions properly. Any ideas? The first, empty ListenStream is intended: It tells systemd to ignore the one provided by the main socket unit in /lib/systemd/system. Otherwise it would open two sockets. >> However while testing this, I noticed another issue: >> The clamav-daemon.socket is not stopped during 'dpkg-reconfigure >> clamav-daemon'. >> Thus after changing the name of the socket, a stale socket file is left >> behind. >> I'm not sure if that's really a problem worth fixing though. Thoughts? > > Leaving stale sockets isn't nice I guess. But it won't happen often I > guess. "stop" - change socket file - "start" would fix it and a reload > due to new options would be done anyway. Would that be a way to fix it? That's how it's fixed now. ;) Best regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
