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.

Sign up for GitHub

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

Jump to bottom

filestore: do not try to store a file set to nostore #11136

Closed
wants to merge 1 commit into from
Closed

filestore: do not try to store a file set to nostore #11136

wants to merge 1 commit into from

Conversation

catenacyber
Copy link
Contributor

Link to redmine ticket:
https://redmine.openinfosecfoundation.org/issues/6390

Describe changes:

  • filestore: do not try to store a file set to nostore

use of keyword filestore:both,flow may try to store a file that has already been opened (in the other direction) and set to nostore...

SV_BRANCH=OISF/suricata-verify#1524

#10877 to get attention if we want to backport this for next 7 release

@catenacyber
filestore: do not try to store a file set to nostore
c00b886 
Ticket: 6390

This can happen with keyword filestore:both,flow
If one direction does not have a signature group with a filestore,
the file is set to nostore on opening, until a signature in
the other direction tries to set it to store.
Subsequent files will be stored in both directions as flow flags
are now set.
@catenacyber catenacyber requested a review from victorjulien as a code owner May 23, 2024 20:07
@catenacyber catenacyber mentioned this pull request May 23, 2024
Closed
@codecov Codecov
Copy link

codecov bot commented May 23, 2024

Codecov Report

Attention: Patch coverage is 50.00000% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 80.89%. Comparing base (b3eb1c4) to head (c00b886).

Additional details and impacted files 
@@            Coverage Diff             @@
##           master   #11136      +/-   ##
==========================================
- Coverage   84.26%   80.89%   -3.37%     
==========================================
  Files         926      926              
  Lines      247387   247212     -175     
==========================================
- Hits       208453   199976    -8477     
- Misses      38934    47236    +8302
Flag Coverage Δ
fuzzcorpus 64.19% <50.00%> (+<0.01%) ⬆️
livemode 19.56% <0.00%> (-0.01%) ⬇️
pcap ?
suricata-verify ?
unittests 61.95% <0.00%> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

@suricata-qa
Copy link

Information: QA ran without warnings.

Pipeline 20759

@victorjulien
Copy link
Member

Can we detect this scenario when we're matching the filestore keyword? If we can avoid setting the flag for the affected direction, we can avoid the set-then-later-unset logic?

@catenacyber
Copy link
Contributor Author

Can we detect this scenario when we're matching the filestore keyword? If we can avoid setting the flag for the affected direction, we can avoid the set-then-later-unset logic?

🤔 matching filestore does the right thing, that is set the file_flags for the AppLayerStateData
But then, about every protocol updates AppLayerTxData file_flags from AppLayerStateData file_flags every time (and not just once on creation), which seems the wrong thing here...
Or SMTP protocol does not seem to handle file_flags at all...

I will come at this again...

@catenacyber catenacyber mentioned this pull request May 28, 2024
Closed
@catenacyber
Copy link
Contributor Author

Continued in #11167

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@victorjulien victorjulien Awaiting requested review from victorjulien victorjulien is a code owner

Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@catenacyber @suricata-qa @victorjulien