Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix #820 - add new option --fail-if-cvd-older-than=days #867

Merged
merged 5 commits into from
Mar 28, 2023
Merged

Fix #820 - add new option --fail-if-cvd-older-than=days #867

merged 5 commits into from
Mar 28, 2023

Conversation

rzvncj
Copy link
Contributor

@rzvncj rzvncj commented Mar 22, 2023

When passed, causes clamscan to exit with a non-zero return code if the virus database is older than the specified number of days.

@rzvncj
Copy link
Contributor Author

rzvncj commented Mar 22, 2023

Please let me know if this is a good start. I'll continue with FailIfCvdOlderThan after we're good with the clamscan part (probably in its own commit).

Copy link
Contributor

@micahsnyder micahsnyder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great start!

I have some suggested changes but nothing functional.

I forgot to mention this on the previous PR, but in the spirit of #841, I would suggest adding both a clamd.conf option as well as a --fail-if-cvd-older-than command line option when you extend this for clamd. Which of course means adding documentatino as well to

  • clamd.conf.sample
  • clamd.conf manpage
  • clamd manpage

libclamav/cvd.c Outdated Show resolved Hide resolved
libclamav/cvd.c Outdated Show resolved Hide resolved
libclamav/cvd.c Outdated Show resolved Hide resolved
libclamav/cvd.c Outdated Show resolved Hide resolved
libclamav/cvd.c Outdated Show resolved Hide resolved
libclamav/cvd.c Outdated Show resolved Hide resolved
clamscan/manager.c Show resolved Hide resolved
libclamav/cvd.c Outdated Show resolved Hide resolved
clamscan/manager.c Outdated Show resolved Hide resolved
clamscan/manager.c Outdated Show resolved Hide resolved
@rzvncj
Copy link
Contributor Author

rzvncj commented Mar 24, 2023

I assume the clamscan part is OK, so I'll start work shortly on the clamd part. Thanks for the quick review so far!

clamscan/manager.c Outdated Show resolved Hide resolved
@micahsnyder
Copy link
Contributor

micahsnyder commented Mar 25, 2023

As a heads up, we're prepping the 1.1 release candidate early next week. It'd be fun to get this in there, but if not it will have to wait for merge until after release in a few weeks, and be included in the following version (1.2) which will be released around August/September-ish.

Edit: To clarify, we don't like adding new features between the release candidate and release, though we may merge minor bug fixes during that time.

@rzvncj
Copy link
Contributor Author

rzvncj commented Mar 26, 2023

As a heads up, we're prepping the 1.1 release candidate early next week. It'd be fun to get this in there, but if not it will have to wait for merge until after release in a few weeks, and be included in the following version (1.2) which will be released around August/September-ish.

Edit: To clarify, we don't like adding new features between the release candidate and release, though we may merge minor bug fixes during that time.

Understood. No problem, I'll do my best to get to the clamd part ASAP. Thanks!

@rzvncj
Copy link
Contributor Author

rzvncj commented Mar 26, 2023

There's an additional clamd cl_load() call in server-th.c (in reload_th()) that I've not treated. I'm assuming that that code only runs after an actual database update so it would be pointless to guard it with check_if_cvd_outdated() but I could be wrong. Please let me know if that's something I should look at again. Thanks!

@rzvncj
Copy link
Contributor Author

rzvncj commented Mar 26, 2023

Also, if you prefer this PR to be in a single commit please let me know and I'm happy to squash and force-commit the result.

@micahsnyder
Copy link
Contributor

There's an additional clamd cl_load() call in server-th.c (in reload_th()) that I've not treated. I'm assuming that that code only runs after an actual database update so it would be pointless to guard it with check_if_cvd_outdated() but I could be wrong. Please let me know if that's something I should look at again. Thanks!

The reload_th use of cl_load() is also done on the self-check that runs every x minutes (default every 10 minutes).
I can imagine someone complaining that they thought it would fail if the database hasn't been updated. But I don't have any strong feels about whether or not is should fail to reload if the database ages past the threshold.

If we do make the reload fail for old cvds, then to solve it I think you'd have to add an engine option to set the max database age. That's maybe more work than you want to do?

If we don't make the reload fail for old cvds, then we should adjust the wording in the clamd.conf.sample and clamd.conf manpage to say something along the lines of "This will not cause a database reload to fail if the database found on reload is older than this limit."

Also, if you prefer this PR to be in a single commit please let me know and I'm happy to squash and force-commit the result.

Don't worry about it, I will squash the commits and reword slightly when I merge it.

Speaking of which, I pushed a change to the win32 equivalent of the clamd.conf.sample for you, because I forgot to mention that it exists and must also be updated.

I'd like your opinion on what you think we should do regarding the reload_th cl_load. And @candrews too if you have thoughts you're welcome to chime in.

Copy link
Contributor

@micahsnyder micahsnyder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In terms of code and documentation, everything looks great to me.

I manually tested clamd and clamscan behavior, including verifying that the clamd reload is not affected by the new options.

Marking as "request changes" because we'll need either a change to the clamd.conf documentation if we choose to keep the reload behavior as-is, or because we'd need more clamd changes to support the option in the reload use case.

@rzvncj
Copy link
Contributor Author

rzvncj commented Mar 27, 2023

There's an additional clamd cl_load() call in server-th.c (in reload_th()) that I've not treated. I'm assuming that that code only runs after an actual database update so it would be pointless to guard it with check_if_cvd_outdated() but I could be wrong. Please let me know if that's something I should look at again. Thanks!

The reload_th use of cl_load() is also done on the self-check that runs every x minutes (default every 10 minutes). I can imagine someone complaining that they thought it would fail if the database hasn't been updated. But I don't have any strong feels about whether or not is should fail to reload if the database ages past the threshold.

If we do make the reload fail for old cvds, then to solve it I think you'd have to add an engine option to set the max database age. That's maybe more work than you want to do?

If we don't make the reload fail for old cvds, then we should adjust the wording in the clamd.conf.sample and clamd.conf manpage to say something along the lines of "This will not cause a database reload to fail if the database found on reload is older than this limit."

The amount of needed work is irrelevant to me, there are only two important factors here IMHO:

  1. Do we want this to be done ASAP (so it makes it into the upcoming release before the freeze this week)?
  2. Do users want this feature? I can't really tell, because it's not something I thought of using before seeing @candrews' open issue, so in this respect his opinion probably carries more weight than mine.

If it's OK to postpone this for the next release (i.e. the answer to the first question is "not necessarily"), and if it makes sense for the cl_load() thread to fail, then I have no problem to continue working on this.

Also, if you prefer this PR to be in a single commit please let me know and I'm happy to squash and force-commit the result.

Don't worry about it, I will squash the commits and reword slightly when I merge it.

Speaking of which, I pushed a change to the win32 equivalent of the clamd.conf.sample for you, because I forgot to mention that it exists and must also be updated.

Thanks! Sorry about missing the Windows part - I guess it shows I'm a UNIX person. :)

@micahsnyder
Copy link
Contributor

The amount of needed work is irrelevant to me, there are only two important factors here IMHO:

  1. Do we want this to be done ASAP (so it makes it into the upcoming release before the freeze this week)?
  2. Do users want this feature? I can't really tell, because it's not something I thought of using before seeing @candrews' open issue, so in this respect his opinion probably carries more weight than mine.

If it's OK to postpone this for the next release (i.e. the answer to the first question is "not necessarily"), and if it makes sense for the cl_load() thread to fail, then I have no problem to continue working on this.

I tested this change to the reload_th behavior to check the CVD age:
cvd_age_check_clamd_reload.patch

What I realized with this patch is that failing the CVD update does not cause clamd to die. Instead it intentionally continues on with the existing databases, which is very likely the preferred behavior.

So then I thought about it a little more about the problem. I realize that the scenario I was trying to account for should not happen. That is, it should only try to run the reload_th function if there was an update to the databases. And if there was an update to the databases then the CVD age should not exceed the limit.

In short, I'm happy with the PR as-is and don't care about any further documentation change after all.

Thanks! Sorry about missing the Windows part - I guess it shows I'm a UNIX person. :)

😆 No worries, I should have said something.

I'll make sure this all passes our automated Jenkins tests, and if so will merge it.

Copy link
Contributor

@micahsnyder micahsnyder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had to make a small change because initializing arrays with = {}; doesn't work on windows -- but you can initialize with = {0};. Outside of that testing looked good.

rzvncj and others added 5 commits March 27, 2023 21:51
When passed, causes clamscan to exit with a non-zero return code
if the virus database is older than the specified number of days.
When passed, causes clamd to exit (on start-up) with a non-zero
return code if the virus database is older than the specified
number of days.

Additionally, we introduce FailIfCvdOlderThan as a clamd.conf
synonym for --fail-if-cvd-older-than.
@micahsnyder
Copy link
Contributor

Actually - one more change. The new clamav.h API in libclamav.map should be in a different namespace: CLAMAV_1.1.0.

@rzvncj
Copy link
Contributor Author

rzvncj commented Mar 28, 2023

Thanks!

@micahsnyder micahsnyder merged commit e4fe665 into Cisco-Talos:main Mar 28, 2023
@rzvncj rzvncj deleted the new-option2 branch March 28, 2023 21:36
@micahsnyder
Copy link
Contributor

Thank you so much for the help @rzvncj

@candrews
Copy link
Contributor

Thank you all! This is really fantastic!

@rzvncj
Copy link
Contributor Author

rzvncj commented Mar 29, 2023

Thank you so much for the help @rzvncj

You're welcome! It's been quick and pleasant. Thanks for the prompt reviews!

candrews added a commit to candrews/clamav-devel that referenced this pull request Mar 31, 2023
* Add new clamd and clamscan option --cache-size

This option allows you to set the number of entries the cache can store.

Additionally, introduce CacheSize as a clamd.conf
synonym for --cache-size.

Fixes Cisco-Talos#867
candrews added a commit to candrews/clamav-devel that referenced this pull request Mar 31, 2023
* Add new clamd and clamscan option --cache-size

This option allows you to set the number of entries the cache can store.

Additionally, introduce CacheSize as a clamd.conf
synonym for --cache-size.

Fixes Cisco-Talos#867
candrews added a commit to candrews/clamav-devel that referenced this pull request Apr 1, 2023
* Add new clamd and clamscan option --cache-size

This option allows you to set the number of entries the cache can store.

Additionally, introduce CacheSize as a clamd.conf
synonym for --cache-size.

Fixes Cisco-Talos#867
candrews added a commit to candrews/clamav-devel that referenced this pull request May 15, 2023
* Add new clamd and clamscan option --cache-size

This option allows you to set the number of entries the cache can store.

Additionally, introduce CacheSize as a clamd.conf
synonym for --cache-size.

Fixes Cisco-Talos#867
micahsnyder pushed a commit to candrews/clamav-devel that referenced this pull request May 16, 2023
* Add new clamd and clamscan option --cache-size

This option allows you to set the number of entries the cache can store.

Additionally, introduce CacheSize as a clamd.conf
synonym for --cache-size.

Fixes Cisco-Talos#867
micahsnyder pushed a commit that referenced this pull request May 17, 2023
* Add new clamd and clamscan option --cache-size

This option allows you to set the number of entries the cache can store.

Additionally, introduce CacheSize as a clamd.conf
synonym for --cache-size.

Fixes #867
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants