Open h4l0gen opened 7 months ago
@leogr @FedeDP Here I first check whether that file exists or not. Then open the file in writing mode. Please provide your feedback and any changes if you need them. Thank You!!
and this rule triggered successfully
@leogr @FedeDP Here I first check whether that file exists or not. Then open the file in writing mode. Please provide your feedback and any changes if you need them. Thank You!!
and this rule triggered successfully
Does the rule trigger when the file does not exist? If yes, avoid the check If not, there're to options when the file does not exist:
@leogr The rule is not triggering when the file doesn't exist. So I made these changes:
If the file doesn't exist:
- Create the file.
- Open it in write-only mode.
- Remove the file after processing.
If the file already exists:
- Open it in write-only mode
- Close the file after processing
Thank you,
SGTM. Just, I'd like to get a second look from @FedeDP :pray:
@FedeDP Cant we write the code like this. WDYT? Like writing defer statement before, bcz it executes after function return so it cleanups perfectly. Also tested with this code and rule triggers fine in both cases file exists and not exists
func UpdatePackageRepository(h events.Helper) error {
path := "/etc/apt/sources.list"
// Check if the file exists and remove it if it is created by you
if _, err := os.Stat(path); err != nil {
defer os.Remove(path)
}
// Open file with writeonly access, create a file if there is none
if _, err := os.OpenFile(path, os.O_WRONLY|os.O_CREATE, os.FileMode(0755)); err != nil {
return err
}
return nil
}
@GLVSKiriti even if more compact, i think it is less readable:
if _, err := os.Stat(path); err != nil {
defer os.Remove(path)
}
defer the remove when stat gives an error is super hard to read if one does not know the full context :)
Thank you, @FedeDP, @leogr and @GLVSKiriti, for your feedback. I agree with @FedeDP; as this project continues to evolve and attract new contributors, it's beneficial to maintain readable code as much as possible. Clear code reduces confusion for newcomers, helping them understand it easily.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stale
Closing and reopening to trigger the CI /close
@leogr: Closed this PR.
/reopen
@leogr: Reopened this PR.
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: h4l0gen Once this PR has been reviewed and has the lgtm label, please assign alacuku for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.
What type of PR is this?
/kind feature
Any specific area of the project related to this PR?
/area events
What this PR does / why we need it: This PR triggers sandbox rule update package repository Which issue(s) this PR fixes:
Fixes #120
Special notes for your reviewer: