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

set[enum] options can't be set and lead to a segfault? #591

grigorescu opened this issue Sep 23, 2019 · 1 comment · Fixed by #617


Copy link

commented Sep 23, 2019

There are a few option variables that ship with Zeek which are of type set[enum], namely:

  • DPD::ignore_violations
  • Notice::alarmed_types
  • Notice::emailed_types
  • Notice::ignored_types
  • Notice::lookup_location_types
  • Notice::not_suppressed_types
  • SMB::logged_file_actions

From what I can tell, to set these without redef needs some really convoluted Zeek scripting. A sample btest, with 2 failures and 1 method that finally works is available at:

The situation is even worse when trying to set these values via the config input reader, as it generally causes a segfault. btests here:

Assigning an empty enum works, but trying to assign an actual enum causes a segfault.

@jsiwek jsiwek referenced this issue Sep 27, 2019
11 of 13 tasks complete
@jsiwek jsiwek added this to Unassigned / Todo in Release 3.0.1 via automation Oct 3, 2019
@jsiwek jsiwek added this to the 3.0.1 milestone Oct 3, 2019
@jsiwek jsiwek self-assigned this Oct 3, 2019
jsiwek added a commit that referenced this issue Oct 3, 2019
@jsiwek jsiwek moved this from Unassigned / Todo to Needs Review / Merge in Release 3.0.1 Oct 3, 2019
0xxon added a commit that referenced this issue Oct 7, 2019

* origin/topic/jsiwek/gh-591-set-enum-config:
  GH-591: allow Config::set_value() to use empty/unspecified table/sets
  GH-591: fix reading set[enum] values from input files
jsiwek added a commit that referenced this issue Oct 14, 2019

This comment has been minimized.

Copy link

commented Oct 14, 2019

Examples should be fixed via #617 now in master and release/3.0 (except the ones using {}, which might be more along the lines of requiring a script-language enhancement rather than fixing a bug).

@jsiwek jsiwek closed this Oct 14, 2019
Release 3.0.1 automation moved this from Needs Review / Merge to Done Oct 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Release 3.0.1
3 participants
You can’t perform that action at this time.