Files with cryptic names get written in / (unix root)

[monkz]

Describe the bug

On Debian/Ubuntu 20.04+ files with cryptic names get written in / (unix root):

-rw-r-----   1 root root     0 Jun  8 13:54 ''$'\006''1'$'\375\226\035''V'
-rw-r-----   1 root root    23 Jun  8 15:24 ''$'\020''hS|NV'
-rw-r-----   1 root root     0 Jun  6 19:09 '"̓]'$'\026''V'
-rw-r-----   1 root root    23 Jun  7 19:09 ''$'\232''(0'$'\336''HV'
-rw-r-----   1 root root    23 Jun 14 13:54 ''$'\242\257''g'$'\212\n''V'
-rw-r-----   1 root root    23 Mär 23 09:18 ''$'\245\034''NP$V'
-rw-r-----   1 root root     0 Jun 12 13:09 ''$'\273\337''u'$'\234\213''U'
-rw-r-----   1 root root     0 Jun 12 00:24 ''$'\275''闹'$'\303''U'
-rw-r-----   1 root root    23 Jun 14 07:54 ''$'\277''Е'$'\236\352''U'
-rw-r-----   1 root root    23 Jun  4 17:39 ''$'\350\020''@'$'\264''7V'
-rw-r-----   1 root root     0 Jun 12 05:39 ''$'\350\035''4'$'\320''}U'

Each file with 23Byte contains the string

ClamScanQueue: stopped

On my system following packages are installed:

clamav-base/groovy-updates,groovy-updates,groovy-security,groovy-security,now 0.103.2+dfsg-0ubuntu0.20.10.2 all [installed,automatic]
clamav-daemon/groovy-updates,groovy-security,now 0.103.2+dfsg-0ubuntu0.20.10.2 amd64 [installed]
clamav-freshclam/groovy-updates,groovy-security,now 0.103.2+dfsg-0ubuntu0.20.10.2 amd64 [installed]
clamdscan/groovy-updates,groovy-security,now 0.103.2+dfsg-0ubuntu0.20.10.2 amd64 [installed]
libclamav9/groovy-updates,groovy-security,now 0.103.2+dfsg-0ubuntu0.20.10.2 amd64 [installed,automatic]

clamav-deamon is running as systemd service (starts as root but drops to user clamav via clamd.conf)
clamonacc is running as systemd service (starts as root and stays root and streams files to clamd)
some clamdscan executions are scheduled via cron (starts as root and uses fdpass)

How to reproduce the problem

systemctl restart clamonacc.service (contents of that service file see below)
have --log in the service file

[micahsnyder]

It looks to me as your systemd service for that starts clamonacc is improperly handling the output. Perhaps executing piping it to Bash instead of writing it to a log file?

Please share the contents of the clamonacc systemd service file.

[monkz]

[Unit]
Description=Clam AntiVirus On Access Scanning
Requires=clamav-daemon.service
After=clamav-daemon.service

[Service]
Type=simple
ExecStart=/usr/sbin/clamonacc --foreground --stream --log=/var/log/clamav/clamonacc.log 

[Install]
WantedBy=multi-user.target

[micahsnyder]

I'm stumped. I have no idea how those files would've gotten there.

[monkz]

Same here. And this is not just me - this happens on multiple systems - all derivatives of debian.

[micahsnyder]

As a side note, if you're using 0.103.2 and clamd is on the same system as clamonacc, I would recommend using clamonacc --fdpass instead of clamonacc --stream. It is much faster than --stream, and like with --stream, it doesn't require clamd to run as root.

[monkz]

Yup, this was from an older version, where fdpass was broken. I'll test this again.

[monkz]

I tried on a different system now.
systemctl restart clamonacc.service is sufficient to produce these files. (just execute it in various frequencies)
But not everytime. There seems to be a race condition.

Sometimes it restarts ok, sometime it creates a file in /, sometime it locks up and will be killed by systemd.

OS: Ubuntu 21.04
Package Version: 0.103.2+dfsg-1ubuntu0.21.04.1

PS: fdpass works

[monkz]

Without

--log=/var/log/clamav/clamonacc.log 

i wasn't able to reproduce the file creation. It still gets stuck sometimes. (On restart)

[micahsnyder]

@monkz I have a sneaking suspicion that this is caused by some undefined behavior

Without

--log=/var/log/clamav/clamonacc.log 

i wasn't able to reproduce the file creation. It still gets stuck sometimes. (On restart)

This is a really good tip. I'm sorry I haven't worked on this yet, but it gives me some ideas. I think it may have to do with how the logging module inside the common static library is linked, used. I think there may be some undefined behavior going on. I wonder if it would be fixed by adding a set_logfile() function into the common/output.c library.

[goshansp]

Stopped using clamonacc --log after some undocumented issues and have not seen any issues since. Logging thru systemd-journald is simple and later the stream can be aggregated by rsyslog into one single file. This enables easy integration with corporate log infrastructures and error filtering.

Rsyslog Config:
https://gitlab.com/goshansp/ansible-role-clamav/-/blob/main/templates/00-clamav-logging.conf.j2

Log Parsing:
https://gitlab.com/goshansp/ansible-role-clamav/-/blob/main/tests/check_log.yml

I think logging should be handled by operating system logging facility. It handles permissions, can do rotation while giving the high flexibility such as log forwarding. Honestly i think --log should be deprecated.

[goshansp]

I revert my take above as I have started using --log on production systems where we cant change ratelimits and need to log from within sytemd in insane volumes to identify exclusions.

[markinson24]

Unfortunately I have exactly the same issue in my LInux Mint Cinnamon 20.3 "Una" (Ubuntu 20.04 focal).
ClamAV version 0.104.0-1.

187 bytes files with names like "�8: <�U (invalid encoding)" or "��q�cU (invalid encoding)" are created under "/".

The content is always the same:
"ERROR: Clamonacc: clamonacc has experienced a fatal error, if you continue to see this error, please run clamonacc with --verbose and report the issue and crash report to the developpers"

The content of my clamonacc.service is as follows:

[Unit]
Description=ClamAV On Access Scanner
Requires=clamav-daemon.service
After=clamav-daemon.service
After=syslog.target
After=network-online.target

[Service]
Type=simple
User=root
ExecStartPre=/bin/bash -c "while [ ! -S /var/run/clamav/clamd.ctl ]; do sleep 1; done"
ExecStart=/usr/sbin/clamonacc -F --fdpass --config-file=/etc/clamav/clamd.conf 	--log=/var/log/clamav/clamonacc.log --move=/home/username/.clamtk/viruses
	
[Install]
WantedBy=multi-user.target

Some advice? Can we intervene in any way?

P.S.
Sorry for my English and my exposition ...

[m-sola]

I could no longer reproduce this issue after the refactor linked above. Let me know if it fixes your issue. If it doesn't, I suspect I'll have to wrap mutexes around logg calls within the threadpool callback function

[markinson24]

Sorry for delay! Now it seems to be all right.

[monkz]

Looks promising 👍