Allow link.OpenExecutable for files without executable bit set#1969
Allow link.OpenExecutable for files without executable bit set#1969shaunduncan wants to merge 1 commit intocilium:mainfrom
Conversation
ti-mo
left a comment
There was a problem hiding this comment.
Thanks for picking this up! Please squash into one commit when you've addressed the feedback.
This change removes the restriction added in PR cilium#1938 that requires file paths given to link.OpenExecutable() have the executable bit set. This restores the previous behvaior in versions prior to v0.21.0 while also preserving the new capabilities introduced in PR cilium#1938. Signed-off-by: Shaun Duncan <shaun@speedscale.com>
|
Hi everyone - I've addressed the feedback, squashed the branch, and re-pushed. Thanks for taking a look! |
|
@shaunduncan I believe there's some related test code failing still |
skymensch
left a comment
There was a problem hiding this comment.
Hey @shaunduncan, the fix looks correct conceptually, but link/uprobe_test.go also needs to be updated to match the new behavior.
Currently, TestExecutable creates a file with mode 0600 and expects OpenExecutable() to return an error:
// uprobe_test.go ~line 41
_, err = OpenExecutable(path)
if err == nil {
t.Fatal("create executable: expected error on non-executable file")
}Since this PR removes that check, OpenExecutable() now succeeds on a 0600 file — so the test fails at that assertion.
The fix is to replace that block (and the subsequent os.Chmod step) with an assertion that expects success:
// OpenExecutable should succeed regardless of execute bit
_, err = OpenExecutable(path)
if err != nil {
t.Fatalf("create executable: unexpected error on non-executable file: %v", err)
}That should make the CI green. 🙂
This change removes the restriction added in PR #1938 that requires file paths given to link.OpenExecutable() have the executable bit set. This restores the previous behvaior in versions prior to v0.21.0 while also preserving the new capabilities introduced in PR #1938.
This should resolve #1964