Bug 259699 - security/clamav: rc-script does not check for existence of /var/run/clamav
Summary: security/clamav: rc-script does not check for existence of /var/run/clamav
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Yasuhiro Kimura
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-11-07 16:23 UTC by O. Hartmann
Modified: 2022-11-19 07:08 UTC (History)
7 users (show)

See Also:
bugzilla: maintainer-feedback? (yasu)


Attachments
Example PID dir aware-making rc script (763 bytes, patch)
2021-11-18 21:13 UTC, O. Hartmann
no flags Details | Diff
Check for existence of /var/run/clamav and create if not exist. (690 bytes, patch)
2022-04-12 15:27 UTC, O. Hartmann
no flags Details | Diff
Initialize /var/run (670 bytes, patch)
2022-08-27 21:02 UTC, Cy Schubert
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description O. Hartmann 2021-11-07 16:23:26 UTC
After a general system udate on 13-STABLE including several packages, security/clamav fails to start after rebooting:

[...]
# service clamav-clamd start
Starting clamav_clamd.
ERROR: Can't save PID to file /var/run/clamav/clamd.pid: No such file or directory
/usr/local/etc/rc.d/clamav-clamd: WARNING: failed to start clamav_clamd

It turns out that the rc script doesn't create and/or does not check for the correct ownership of /var/run/clamav folder. Creating this folder with ownership clamav:clamav makes clamav clamd working again as expected.

OS: FreeBSD 13.0-STABLE #21 stable/13-n248012-b6b91760300: Sat Nov  6 19:58:32 CET 2021 amd64

 # pkg info -xo clamav
clamav-0.104.0,1               security/clamav
Comment 1 Oclair 2021-11-07 17:42:56 UTC
It appears that the clamav port no longer adheres to /etc/make.conf

CLAMAVUSER=vscan
CLAMAVGROUP=vscan

Additionally I've just had an instance where I had to again change perms on /var/run/clamav to vscan:vscan because for some reason clamav was running again as user clamav ignoring the config file at /usr/local/etc/clamd.conf 

User vscan

This issue was recently introduced and has been causing interruptions of mail delivery.

Kind Regards,
Comment 2 Yasuhiro Kimura freebsd_committer freebsd_triage 2021-11-07 21:39:13 UTC
(In reply to Oclair from comment #1)

It's obviously different problem from the one that O. Hartmann reports. So please don't mix multiple problems and open new bug report.
Comment 3 Oclair 2021-11-07 21:41:01 UTC
(In reply to Yasuhiro Kimura from comment #2)
not true my issue started with that exact error and I am reporting a possible cause
Comment 4 Yasuhiro Kimura freebsd_committer freebsd_triage 2021-11-07 21:42:35 UTC
(In reply to O. Hartmann from comment #0)

/var/run should be created with correct owner/group when package is installed. Did you remove the directory manually after installing/upgrading the package?
Comment 5 Oclair 2021-11-07 21:49:24 UTC
>/var/run should be created with correct owner/group when package is installed.  

no make.conf decides what correct is and the latest update changed the owner by ignoring make.conf entries 

CLAMAVUSER=vscan
CLAMAVGROUP=vscan

Thus 
># service clamav-clamd start
>Starting clamav_clamd.
>ERROR: Can't save PID to file /var/run/clamav/clamd.pid: No such file or directory
Comment 6 Yasuhiro Kimura freebsd_committer freebsd_triage 2021-11-07 21:56:20 UTC
(In reply to Oclair from comment #5)

Please don't overlook that comment #4 starts with following line.

> (In reply to O. Hartmann from comment #0)

As is written it's reply to not you but O. Hartmann.

And again, please open new bug report. Your problem is different from that of O. Hartmann.
Comment 7 Oclair 2021-11-07 22:44:34 UTC
I hope this was a one time incident where updating the clamav port results in /usr/local/etc/rc.d/clamav-clamd: WARNING: failed to start clamav_clamd
Comment 8 O. Hartmann 2021-11-08 16:49:43 UTC
(In reply to Yasuhiro Kimura from comment #4)

Whe the packages is installed first time, the correct folder is also initialized. But on many installations of ours, /var/run is on a TEMPFS filesystem, so it vanishes after the host shuts down or reboots.

I also use this type of installation for several security considerations on laptops.
Comment 9 O. Hartmann 2021-11-18 20:32:10 UTC
This problem is really(!) nasty. claws-mail rejects to start when clamav is not running.

Checkout the rc-script taken from net/nss-pam-ldapd-sasl, located at 

/usr/local/etc/rc.d/nslcd

You find in the nslcd_prestart() routine the line 

install -d -o nslcd -g nslcd /var/run/nslcd.

Why not adapting this line and enrich the clamav-rc-script with

CLAMAV_UID=clamav
CLAMAV_GID=clamav
install -d -o ${CLAMAV_UID} -g ${CLAMAV_GID} -m 750 /var/run/calmav
Comment 10 O. Hartmann 2021-11-18 21:13:15 UTC
Created attachment 229584 [details]
Example PID dir aware-making rc script

The patchfile is for your consideration.
Comment 11 Yasuhiro Kimura freebsd_committer freebsd_triage 2021-12-14 01:41:15 UTC
(In reply to O. Hartmann from comment #8)

You should not use tmpfs for /var/run as it breaks file system hierarchy defined in hier(7).
Comment 12 O. Hartmann 2022-04-12 15:27:37 UTC
Created attachment 233170 [details]
Check for existence of /var/run/clamav and create if not exist.

The problem still reoccurs when updates of the port are performed! Please add the attached patch.
Thanks.
Comment 13 O. Hartmann 2022-08-27 06:11:45 UTC
This problem and the one described in PR 259585 is still open and is harming security sensitive installations where /var/run is created in memory on boot time (tmpfs). This not uncommon feature breaks this port.

I will put the discussion in a wider and open forum to hear what solution can be found.
Comment 14 Juraj Lutter freebsd_committer freebsd_triage 2022-08-27 11:26:30 UTC
There are two places where clamd stores its data:

PidFile
LocalSocket

Both of them are by default under /var/run/clamav so the rc.d script should check the config file for presence of these settings and create the respective directories as they don't necessarily need to be under the same location.
Comment 15 Jamie Landeg-Jones 2022-08-27 14:38:53 UTC
(In reply to Yasuhiro Kimura from comment #11)

I also run /var/run on a tmpfs, and have had similar problem with a number of ports, so I now basically have a seperate boot up script that populates /var/run as necessary on mount.

It's messy though, and shouldn't be needed.

> You should not use tmpfs for /var/run as it breaks file system hierarchy defined in hier(7).

How? hier says:

> system information files describing various info about system since it was booted

Rather than being against heir, that implies an empty /var/run on boot is preferable!
Comment 16 Cy Schubert freebsd_committer freebsd_triage 2022-08-27 21:02:54 UTC
Created attachment 236166 [details]
Initialize /var/run

This will work for all ports. Uncomment the stop target if you prefer to save the mtree manually.
Comment 17 commit-hook freebsd_committer freebsd_triage 2022-09-05 13:21:00 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=27b9777c28b4e9474bdc500c28d04feec48fbb84

commit 27b9777c28b4e9474bdc500c28d04feec48fbb84
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2022-08-28 12:48:25 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2022-09-05 13:19:42 +0000

    libexec/rc: Add var_run rc script

    Users with a tmpfs /var/run will lose the directory tree state of
    /var/run at reboot. This rc script will optionally (by default)
    capture the state of the directory structure in /var/run prior to
    shutdown and recreate it at system boot.

    Alternatively a user can save the state of the /var/run directories
    manually using service var_run save and disable the autosaving of
    /var/run state using the var_run_autosave variable, for those
    paranoid SSD users.

    PR:                     259585, 259699
    Reported by:            freebsd@walstatt-de.de,
    Reviewed by:            philip, gbe (previous version)
    MFC after:              1 week
    Differential Revision:  https://reviews.freebsd.org/D36386

 etc/mtree/BSD.var.dist           |  2 ++
 libexec/rc/rc.conf               |  6 +++++
 libexec/rc/rc.d/Makefile         |  1 +
 libexec/rc/rc.d/var_run (new +x) | 47 ++++++++++++++++++++++++++++++++++++++++
 share/man/man5/rc.conf.5         | 28 ++++++++++++++++++++++++
 5 files changed, 84 insertions(+)
Comment 18 commit-hook freebsd_committer freebsd_triage 2022-09-12 00:41:28 UTC
A commit in branch stable/13 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=3418c14040f240f0b7be9b2688c3682efcd5a7b2

commit 3418c14040f240f0b7be9b2688c3682efcd5a7b2
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2022-08-28 12:48:25 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2022-09-12 00:40:37 +0000

    libexec/rc: Add var_run rc script

    Users with a tmpfs /var/run will lose the directory tree state of
    /var/run at reboot. This rc script will optionally (by default)
    capture the state of the directory structure in /var/run prior to
    shutdown and recreate it at system boot.

    Alternatively a user can save the state of the /var/run directories
    manually using service var_run save and disable the autosaving of
    /var/run state using the var_run_autosave variable, for those
    paranoid SSD users.

    PR:                     259585, 259699
    Reported by:            freebsd@walstatt-de.de,
    Reviewed by:            philip, gbe (previous version)
    Differential Revision:  https://reviews.freebsd.org/D36386

    (cherry picked from commit 27b9777c28b4e9474bdc500c28d04feec48fbb84)

 etc/mtree/BSD.var.dist           |  2 ++
 libexec/rc/rc.conf               |  6 +++++
 libexec/rc/rc.d/Makefile         |  1 +
 libexec/rc/rc.d/var_run (new +x) | 47 ++++++++++++++++++++++++++++++++++++++++
 share/man/man5/rc.conf.5         | 28 ++++++++++++++++++++++++
 5 files changed, 84 insertions(+)
Comment 19 commit-hook freebsd_committer freebsd_triage 2022-09-12 00:44:33 UTC
A commit in branch stable/12 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=eb3e5718bfba6e39d5dd34238b789ffaed974fad

commit eb3e5718bfba6e39d5dd34238b789ffaed974fad
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2022-08-28 12:48:25 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2022-09-12 00:43:42 +0000

    libexec/rc: Add var_run rc script

    Users with a tmpfs /var/run will lose the directory tree state of
    /var/run at reboot. This rc script will optionally (by default)
    capture the state of the directory structure in /var/run prior to
    shutdown and recreate it at system boot.

    Alternatively a user can save the state of the /var/run directories
    manually using service var_run save and disable the autosaving of
    /var/run state using the var_run_autosave variable, for those
    paranoid SSD users.

    PR:                     259585, 259699
    Reported by:            freebsd@walstatt-de.de,
    Reviewed by:            philip, gbe (previous version)
    Differential Revision:  https://reviews.freebsd.org/D36386

    (cherry picked from commit 27b9777c28b4e9474bdc500c28d04feec48fbb84)

 etc/mtree/BSD.var.dist           |  2 ++
 libexec/rc/rc.conf               |  6 +++++
 libexec/rc/rc.d/Makefile         |  1 +
 libexec/rc/rc.d/var_run (new +x) | 47 ++++++++++++++++++++++++++++++++++++++++
 share/man/man5/rc.conf.5         | 28 ++++++++++++++++++++++++
 5 files changed, 84 insertions(+)
Comment 20 Cy Schubert freebsd_committer freebsd_triage 2022-09-12 00:49:09 UTC
You will need a sufficiently populated /var/run, one that contains all the directories needed by our system and the apps running on it. Set var_run_enable="YES" in rc.conf and reboot.