-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
New transformer: getopt(<args>, <optstring>)
#1928
Comments
I am rooting for this new feature! Unfortunately, sometimes we can't make rules precisely on a syscall, and we end up building it on the command line (
Lastly, if we are going in this direction, I would say that implementing |
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
/remove-lifecycle stale |
Motivation
By introducing a transformer that works like the C
getopt()
function, rules authors can more easily match and handle POSIX command-line arguments. This addition will streamline the creation of rules involving command-line options, ensuring greater flexibility and accuracy in rule writing.Feature
Introduce a
getopt(<args>, <optstring>)
transformer to handle command-line arguments, mimicking the functionality of the Cgetopt()
function.Usage examples:
(n, t) in getopt(proc.args, "nt:")
getopt(proc.args, "nt:")[t] = val
getopt(proc.args, "nt:") intersects (n, t)
Alternatives
Doing nothing and sticking with the current way of handling this does not seem a compelling alternative:
Additional context
Design consideration: it is yet to be decided whether the
getopt(<args>, <optstring>)
transformer should mimic thegetopt_long()
function (which also accepts long options starting with two dashes) or if bothgetopt
andgetopt_long
transformers should be introduced. This design choice can be deferred to the implementation stage.References:
cc @darryk10 @loresuso
The text was updated successfully, but these errors were encountered: