RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1674541 - The cached passwd structure about a user is not updated if a user gets authenticated through PAM
Summary: The cached passwd structure about a user is not updated if a user gets authen...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openssh
Version: 7.7
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: rc
: ---
Assignee: Jakub Jelen
QA Contact: Andrej Dzilský
URL:
Whiteboard:
Depends On:
Blocks: 1664402 1685142
TreeView+ depends on / blocked
 
Reported: 2019-02-11 15:33 UTC by Andreas Schneider
Modified: 2019-07-26 12:43 UTC (History)
7 users (show)

Fixed In Version: openssh-7.4p1-19.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1685142 (view as bug list)
Environment:
Last Closed: 2019-07-26 12:43:35 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
proposed patch from upstream mail (1.38 KB, patch)
2019-02-20 09:07 UTC, Jakub Jelen 		no flags Details | Diff
new patch (1.83 KB, patch)
2019-05-21 14:34 UTC, Jakub Jelen 		no flags Details | Diff
Show Obsolete (2) View All

Description Andreas Schneider 2019-02-11 15:33:47 UTC 
Description of problem:

When PAM is setup to authenticate Windows domain users with pam_winbind and Samba's winbindd is running, there is a bug that a user context is set up with a wrong gid.

Samba only gets a valid access token upon successful authentication from a Domain Controller. This access token has all group memberships which have been calculated by a DC. The access token is cached and once it is cache the system can work with correct information.

If an Active Directory domain user logs in via SSH the first time, the cache is empty.

openssh looks up the username using getpwnam(). It then stores the 'struct passwd' in the session structure.

If know the user is authenticated using PAM through pam_winbind we get the correct access token and cache it. However openssh doesn't update the passwd structure to have correct user information, but sets up the user context (setuid, setgid, initgroups) using the outdated information.

The openssh server should update the passwd structure using getpwuid() before it sets up the users context!
Comment 2 Simo Sorce 2019-02-11 15:39:54 UTC 
This issue was not selected to be included either in Red Hat Enterprise Linux 7.7 because it is seen either as low or moderate impact to a small amount of use-cases. The next release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available. We will now close this issue, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open; otherwise we recommend moving the request to Red Hat Enterprise Linux 8 if applicable.
Comment 3 Andreas Schneider 2019-02-11 16:10:28 UTC 
Reopening!
Comment 4 Jakub Jelen 2019-02-20 09:07:37 UTC 
Created attachment 1536621 [details]
proposed patch from upstream mail

The proposed patch is attached to the upstream discussion:

https://lists.mindrot.org/pipermail/openssh-unix-dev/2019-February/037556.html
Comment 14 Andreas Schneider 2019-03-11 14:11:01 UTC 
Andrej, by default a users primary group is "Domain Users". That you see the effect you need to change the primary of the user you're testing with a different group than "Domain Users". The issue is that the users default group is "Domain Users" ...
Comment 16 Andreas Schneider 2019-03-12 13:41:19 UTC 
This means that maybe the patch I created calls getpwuid() at the wrong location (or too late) in the code.
Comment 17 Jakub Jelen 2019-03-12 14:53:10 UTC 
The call to getpwuid() is in the correct place, just before sshd calling the permanently_set_uid() and initgroups() in do_setusercontext(), which takes care of the changing of UID and GID. Can not this be cached somewhere deeper in nsswitch?

I would ask you to run the sshd in debug mode (-ddd switches or LogLevel DEBUG3 in sshd_config) and under strace (with -ff to get the traces for all the children processes) to verify what does it do? You will probably need to configure the sshd to disable sandboxing using "UsePrivilegeSeparation yes" in sshd_config.
Comment 18 Andreas Schneider 2019-03-12 15:53:23 UTC 
Either there is nscd running or there is a winbind cache. I would need winbind debug logs for that to check.
Comment 21 Andreas Schneider 2019-04-23 16:03:54 UTC 
winbindd_dual_ndrcmd: Running command WBINT_GETNSSINFO (no domain)
 931                   info: struct wbint_userinfo                                                                                                                                           
 932                       domain_name              : *                                                                                                                                      
 933                           domain_name              : 'ORPHANTRUST'                                                                                                                      
 934                       acct_name                : *                                                                                                                                      
 935                           acct_name                : 'wrong_gid'

...

result                   : NT_STATUS_REQUEST_NOT_ACCEPTED


This is strange. Also the log.winbind seems to have the log from log.winbindd-idmap. I do not see incoming getpwnam() calls from NSS. I can try to reproduce it it with the ssh package tomorrow.
Comment 25 Jakub Jelen 2019-05-21 14:34:41 UTC 
Created attachment 1571665 [details]
new patch

From the bug #1712053 I figured out few more things that one needs to take care of when changing the group information in the openssh this late. Can you retest with the following scratch build, which should take care of that better?

https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=21776613

The current patch is attached.
Comment 28 Petr Hruska 2019-05-27 07:34:37 UTC 
After taking openssh-7.9p1-updated-cached-pw.patch patch, it has side effect to following test. Problem noticed in F30 release. But can be seen also in F29.
1st. create two users with the same UID/GID. (adduser -o option).
2nd. Log in. Second user is authenticated correctly, but then bash is started as user 1.

Can be reproduced always.
Comment 29 Jakub Jelen 2019-05-27 09:42:30 UTC 
I am dropping the patch also from Fedora now, before we will figure out some better way how to do that. I would not say that creating 2 users with the same uid would be something that we could support or recommend, but this patch was wrong breaking existing use cases badly.
Note You need to log in before you can comment on or make changes to this bug.