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

pam/go/exec: Code cleanup #822

Open
wants to merge 7 commits into
base: main
Choose a base branch
from
Open

pam/go/exec: Code cleanup #822

wants to merge 7 commits into from

Conversation

3v1n0
Copy link
Collaborator

@3v1n0 3v1n0 commented Mar 3, 2025

Some random cleanups on the exec module, see commits for datails

UDENG-6256

@3v1n0 3v1n0 requested a review from a team as a code owner March 3, 2025 19:47
@codecov-commenter
Copy link

codecov-commenter commented Mar 3, 2025

Codecov Report

Attention: Patch coverage is 43.75000% with 27 lines in your changes missing coverage. Please review.

Project coverage is 78.97%. Comparing base (36511cd) to head (6e21c34).
Report is 449 commits behind head on main.

Files with missing lines Patch % Lines
...integration-tests/cmd/exec-client/modulewrapper.go 16.66% 20 Missing ⚠️
pam/go-exec/module.c 68.18% 5 Missing and 2 partials ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #822      +/-   ##
==========================================
- Coverage   83.43%   78.97%   -4.47%     
==========================================
  Files          83      102      +19     
  Lines        8689    10414    +1725     
  Branches       74       75       +1     
==========================================
+ Hits         7250     8224     +974     
- Misses       1111     1725     +614     
- Partials      328      465     +137     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

3v1n0 added 4 commits March 3, 2025 19:56
We may end up modifying it while calling `g_debug` so make sure we're
actually using the real errno on return.
We can safely call g_connection_close multiple times on a valid
connection, while we already have code handling the connection disposal
in action_module_data_cleanup().

At the same time here there's no risk that we're accessing to a disposed
connection in the thread, because at this point the wait-child thread is
running while the action-thread is waiting for it, before disposing the
connection.
Since the pointer is shared through different threads it's safer to
always read and set it atomically, even if there are no races here but
the API makes it more explicit.
Also no need to set the exit code in such cases, as it's just a system
failure from the PAM side.
@3v1n0 3v1n0 force-pushed the exec-cleanups branch 3 times, most recently from 5dacb53 to eda4f14 Compare March 3, 2025 21:15
3v1n0 added 2 commits March 3, 2025 21:27
When the child receives signals should ignore them and just return a
generic PAM system error, but still we need to check that they're
properly handled
Sadly some signals such as SIGABRT or SIGSEGV are handled by go and in
the wrong way because it never redirects them as expected, so in such
cases we just fail with a normal exit error instead of because of a
signal.

Reported this upstream and adding comments about.

See: golang/go#72084
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants