Bug 1686442
| Summary: | Add some useful syslog messages to pam_unix | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | amitkuma |
| Component: | pam | Assignee: | Tomas Mraz <tmraz> |
| Status: | CLOSED ERRATA | QA Contact: | Dalibor Pospíšil <dapospis> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.0 | CC: | daniele, dapospis, tmraz |
| Target Milestone: | rc | Keywords: | FutureFeature, Reopened, Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | pam-1.3.1-5.el8 | Doc Type: | No Doc Update |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-04-28 16:42:43 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
amitkuma
2019-03-07 13:29:11 UTC
Removal of x from /etc/passwd is simply indication that the given user does not use /etc/shadow anymore. Do not do that if that is the intention. This is one of the most basic things about unix account system and it is definitely not a role of PAM to educate sys admins about such stuff. Hi, pam_unix behave as the code say, but the debug messages are not printed in syslog. https://github.com/linux-pam/linux-pam/blob/master/modules/pam_unix/pam_unix_auth.c#L149 > D(("user '%s' has blank passwd", name)); D is defined of course in pam package https://github.com/linux-pam/linux-pam/blob/master/libpam/include/security/_pam_macros.h#L149 """ #define D(x) do { \ _pam_output_debug_info(__FILE__, __FUNCTION__, __LINE__); \ _pam_output_debug x ; \ } while (0) """ test ~ # grep -re debug /etc/rsyslog.conf /etc/rsyslog.d/* /etc/rsyslog.d/05-debug.conf:*.debug /var/log/debug.log test ~ # test ~ # grep pam_unix /etc/pam.d/system-auth auth sufficient pam_unix.so nullok try_first_pass debug account required pam_unix.so nullok try_first_pass broken_shadow no_pass_expiry password sufficient pam_unix.so remember=23 sha512 shadow nullok use_authtok session sufficient pam_unix.so test ~ # """ [1]+ tail -f /var/log/debug.log & test ~ # logger auth.debug test test ~ # Feb 26 17:37:58 test user: auth.debug test test ~ # su - user Feb 26 17:38:04 test su: (to user) user on pts/1 Feb 26 17:38:04 test su: pam_unix(su-l:session): session opened for user user by user(uid=0) [<a href="mailto:user@test">user@test</a> ~]$ su - Feb 26 17:38:07 test su: pam_localuser(su-l:auth): checking "root::0:0:root:/root:/bin/bash#012" Feb 26 17:38:07 test su: pam_unix(su-l:account): unrecognized option [no_pass_expiry] Feb 26 17:38:07 test su: (to root) user on pts/1 Feb 26 17:38:07 test su: pam_unix(su-l:session): session opened for user root by user(uid=1002382) test ~ # logout Feb 26 17:38:13 test su: pam_unix(su-l:session): session closed for user root [<a href="mailto:user@test">user@test</a> ~]$ logout Feb 26 17:38:14 test su: pam_unix(su-l:session): session closed for user user test ~ # """ Thanks, Daniele The debug messages are not built in. The debug messages availability is a build time option and we do not want these to be built in for production code. Despite the fact that I personally think that debug logs can be useful, I think that "we do not want these to be built in for production" has to be analyzed. reasons: - usage of debug is listed in https://access.redhat.com/articles/1314883 for pam_unix as well as the man page (in example) and no info that this is not available. - if i write "debug" in pam_unix, i am aware of what i am doing (or anyway man page can refer it). For the specific issue, my feeling is also that "user '%s' has blank passwd" is not a debug message, but info level. No, the debug option enables different messages than those from D() macro in the code. We can talk about moving some particular message D() to debug option logging or even to info message as a RFE, but due to the constraints on RFEs on RHEL-7 it should be reported against RHEL-8. ||The debug messages are not built in. The debug messages availability is a build time option and we do not want these to be built in for production code. - Then what is the way if someone want pam to be debugged, Since, customers cannot 'make; make install' pam packages for watching the debug messages. ||Yes I feel better option is to move (Some Messages + Info Messages) We can talk about moving some particular message D() to debug option logging or even to info message as a RFE. ||but due to the constraints on RFEs on RHEL-7 it should be reported against RHEL-8. -> Ok, Let us take Customer's opinion on this? Reopening the bugzilla. Hello, Customer is looking to add following into debug messages. =======Created By: Daniele Palumbo (3/22/2019 7:18 PM)========== Please understand that here we would like to have more debug generally, so if Eng can do a quick review over D() current macro, i think this would be the best. Also tomas told that he agree on moving "some" messages (not all for sure, but open to do "not only that one") Our candidates: https://github.com/linux-pam/linux-pam/blob/master/modules/pam_unix/pam_unix_auth.c#L133 https://github.com/linux-pam/linux-pam/blob/master/modules/pam_unix/pam_unix_auth.c#L135 https://github.com/linux-pam/linux-pam/blob/master/modules/pam_unix/pam_unix_auth.c#L162 This has been done pretty much quickly, so feel free to counter/add/remove messages. The most important remain for sure: https://github.com/linux-pam/linux-pam/blob/master/modules/pam_unix/pam_unix_auth.c#L149 =========================================================================== The debug message from line 162 does not seem to me to be a good candidate for conversion as this is something that does not really indicate anything that has any significance on production machines. Otherwise, I am OK with converting these to debug syslog messages which would be issued with the debug option. Dear tomas.
I feel you are correct.
Rather we can modify the Log something as, or something similar!
D(("No User cached Authentication token found!"));
inplace of
D(("conversation function is not ready yet"));
I have conveyed your thoughts to Customer, Waiting for his response.
No, there should not be production debug message in this case at all. I am not talking about the text. Dear tomas,
Customer is fine to have this message in debug:
D(("No User cached Authentication token found!"));
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:1780 |