RFE: More documentation around expectations of applications vs. modules
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Stale
- Domain
- documentation
Research direction
Start by reviewing the ADG and MWG, which the issue says do not cover the application–module process-state contract. Use the cockpit-session alarm() example and the listed POSIX state as concrete cases to investigate. Done means documenting what applications may do, what modules must tolerate (especially before forking), and whether a post-fork/pre-exec sanitizing helper is warranted.
Written by the indexing model from the issue text.
Description
I've skimmed the ADG and the MWG but I've yet to find any information on any sort of contract between the application developer and PAM modules on treatment about process state.
Specifically: there's quite a lot of process state in POSIX:
- signal dispositions
- signal handlers
- per-thread signal mask
- open file descriptors (including those not marked cloexec)
- controlling terminal
- working directory
alarm(2)set or not- many many more
and quite a lot of those survive across fork() and exec().
The problem is that application developers might make use of those features, and module writers might not think about application developers who use those features. There's currently no way to find out about these problems until someone mixes an application doing X with a module that didn't expect that.
I found out about this recently when as an application (cockpit-session) we set an alarm() during the login process and found out that this gets unexpectedly carried into subprocesses forked off by PAM modules.
So here's the ask: a rigorous treatment of these weird process-state type questions in terms of:
- what an application is forbidden to do to their process before interacting with PAM
- what module authors must tolerate in terms of the state of the process that they find themselves running in, with particular detail paid to the question of considerations before forking off subprocesses
- perhaps a helper function that can be run in the post-
fork()/pre-exec()environment of a module to help "sanitize" the subprocess
- Dominant language
- C
- Stars
- 807
- Forks
- 368
- Avg merge
- 6d 16h
- Merged PRs (30d)
- 4
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from linux-pam/linux-pam
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
Difficulty 4/5 3-5 days Newbie friendliness 47/100
All issues in linux-pam/linux-pam
Similar issues
-
Issue-Bug Needs-Triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
ly05010419/MacNativeGames#2001 ·
Maintainers usually reply within 1 day
-
area/docdb kind/bug priority/medium status/awaiting-triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
yugabyte/yugabyte-db#37426 ·
Maintainers usually reply within 1 day
-
area/documentation
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
obsproject/obs-studio#14184 ·
Maintainers usually reply within 1 day