When a CREATE request contains the FILE_DELETE_ON_CLOSE option and
the subsequent CREATE response indicates success, we now raise the
smb2_file_delete event to log a delete action in smb_files.log and
also give users a way to handle this scenario.
The provided pcap was generated locally by recording a smbtorture run
of the smb2.delete-on-close-perms test case.
Placed the create_options into the CmdInfo record for potential
exposure in smb_cmd.log (wasn't sure how that would look so left it
for the future).
Fixes#2276.
* topic/christian/gh-2239-stdin-ctrl-c:
Stop signal-masking upon running unit tests
Pause signal-masking during script parsing
Add btests to verify Zeek's handling of SIGTERM and reading stdin
Add procps/procps-ng to several CI Docker images
* 'update' of https://github.com/leres/zeek:
Restore accidently deleted line
Fix tail -F semantics when want_record=F and add tests for the new features
While writing a test for the new "tail -F semantics" I found that
the $want_record=F case was broken (errno 25). So instead of opening
/dev/null when the input file is missing change READER_RAW to avoid
I/O until it can be opened.
Add two tests, one for when the event handler is called with a
record and one for when it's called with a string.
Ensure the framework's log stream exists prior to using it in zeek_init(), and
use a node-is-live message similar to those in agent and controller also in
launched nodes.
* origin/topic/timw/more-bro-renaming:
Rename bro_version and BRO_PLUGIN_BRO_VERSION to zeek names
Update binpac, bifcl, and gen-zam submodules for renaming changes
Deprecate BRO_PLUGIN_API_VERSION, create zeek::PLUGIN_API_VERSION
Deprecate HOOK_BRO_OBJ_DTOR and related methods
Miscellaneous deprecations and renaming
Rename all of bro lexer methods and such
Stop installing the bro symlink, it's been long enough
Deprecate bro_inet_ntop.{c,h}
Deprecate bro_int_t and bro_uint_t
The sequence of
- adding a new file
- deleting an existing one
- waiting for Zeek to notice the addition
- re-adding the pre-existing file
was prone to a race: it could happen that Zeek's directory observation would see
the new file in one round, and by the time the next round happens the removal
and re-addition had already happened, thus missing the change and failing the
test.
This avoids the race by placing the removal of the existing file before the
addition of the new one, ensuring that when Zeek notices the addition (and
pushes the test to the next round), it has also seen the removal, so the
re-addition cannot get lost.
Failing to do so could open a race condition in which a quickly connecting
controller could send instructions whose resulting Supervisor interactions got
lost.