* mutiuser request_key in both ntlmssp and krb5 @ 2020-09-17 2:07 Shyam Prasad N 2020-09-17 9:23 ` Aurélien Aptel 0 siblings, 1 reply; 6+ messages in thread From: Shyam Prasad N @ 2020-09-17 2:07 UTC (permalink / raw) To: Steve French, Pavel Shilovsky, Paulo Alcantara, CIFS Hi, I was going through the code path in cifs.ko where we get the credentials of an user using request_key mechanism. And I think there may be an issue in both ntlmssp and krb5 case. 1. For ntlmssp, I see that the credentials are stored in the keyring with IPv4 or IPv6 address as the key. Suppose the mount was initially done using hostname, and IP address changes (more likely in Azure scenario), we may end up looking for credentials with the wrong key. 2. For ntlmssp, if I add another user credentials to the keyring using cifscreds, doesn’t that overwrite the prev user’s credentials? Or is there a way to store multiple credentials for the same server? 3. For krb5, and multiuser mount, how should cifs.ko get the username for a user? Currently, I don’t think we read the username from anywhere. -- -Shyam ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: mutiuser request_key in both ntlmssp and krb5 2020-09-17 2:07 mutiuser request_key in both ntlmssp and krb5 Shyam Prasad N @ 2020-09-17 9:23 ` Aurélien Aptel 2020-09-17 9:35 ` Aurélien Aptel 0 siblings, 1 reply; 6+ messages in thread From: Aurélien Aptel @ 2020-09-17 9:23 UTC (permalink / raw) To: Shyam Prasad N, Steve French, Pavel Shilovsky, Paulo Alcantara, CIFS Shyam Prasad N <nspmangalore@gmail.com> writes: > 1. For ntlmssp, I see that the credentials are stored in the keyring > with IPv4 or IPv6 address as the key. Suppose the mount was initially > done using hostname, and IP address changes (more likely in Azure > scenario), we may end up looking for credentials with the wrong key. Yes I thought the same thing.. I'm not sure why the decision to use IP was made. > 2. For ntlmssp, if I add another user credentials to the keyring using > cifscreds, doesn’t that overwrite the prev user’s credentials? Or is > there a way to store multiple credentials for the same server? IIRC the keyring used is the session one, so each user gets a different keyring. > 3. For krb5, and multiuser mount, how should cifs.ko get the username > for a user? Currently, I don’t think we read the username from > anywhere. Remember that all code running in cifs.ko is always in the context of a process (or a kthread which is also using struct task). It's the process who does some syscall that calls cifs.ko. So within the kernel code you can always access the calling process task via the 'current' pointer. We use current_fsuid() to get the current uid. Cheers, -- Aurélien Aptel / SUSE Labs Samba Team GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: mutiuser request_key in both ntlmssp and krb5 2020-09-17 9:23 ` Aurélien Aptel @ 2020-09-17 9:35 ` Aurélien Aptel [not found] ` <CAH2r5muiYZGr=1rZHobpKXAtG+OCDORZok_acOkL6TQssVrm3Q@mail.gmail.com> 0 siblings, 1 reply; 6+ messages in thread From: Aurélien Aptel @ 2020-09-17 9:35 UTC (permalink / raw) To: Shyam Prasad N, Steve French, Pavel Shilovsky, Paulo Alcantara, CIFS Aurélien Aptel <aaptel@suse.com> writes: > Shyam Prasad N <nspmangalore@gmail.com> writes: >> 1. For ntlmssp, I see that the credentials are stored in the keyring >> with IPv4 or IPv6 address as the key. Suppose the mount was initially >> done using hostname, and IP address changes (more likely in Azure >> scenario), we may end up looking for credentials with the wrong key. > > Yes I thought the same thing.. I'm not sure why the decision to use IP > was made. I suspect this code predates the existence of the in-kernel DNS resolver. Just a guess. Cheers, -- Aurélien Aptel / SUSE Labs Samba Team GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München) ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <CAH2r5muiYZGr=1rZHobpKXAtG+OCDORZok_acOkL6TQssVrm3Q@mail.gmail.com>]
* Re: mutiuser request_key in both ntlmssp and krb5 [not found] ` <CAH2r5muiYZGr=1rZHobpKXAtG+OCDORZok_acOkL6TQssVrm3Q@mail.gmail.com> @ 2020-09-21 4:23 ` Shyam Prasad N 2020-09-21 9:31 ` Aurélien Aptel 0 siblings, 1 reply; 6+ messages in thread From: Shyam Prasad N @ 2020-09-21 4:23 UTC (permalink / raw) To: Steve French; +Cc: Aurélien Aptel, Pavel Shilovsky, Paulo Alcantara, CIFS Sorry for the late reply on this. Was out for a few days. > IIRC the keyring used is the session one, so each user gets a different keyring. Ah, I see. So I'm wondering how the multiuser mounts for ntlmssp work? On each login, does the user have to populate the keyring with his/her credentials? > Remember that all code running in cifs.ko is always in the context of a > process (or a kthread which is also using struct task). It's the process > who does some syscall that calls cifs.ko. So within the kernel code you > can always access the calling process task via the 'current' pointer. > > We use current_fsuid() to get the current uid. Agreed for majority cases. But Steve makes a good point that this only gets us the local uid/username. However, the actual domain user name could be very different. For example, local user user1 could be logged in as domain1\user1 or domain2\user1. How do we handle this scenario? I'm guessing (please correct me if I'm wrong here) that an user session corresponds to only one of those two remote users (domain1\user1 or domain2\user1). In that case, how do we get the fully qualified name in the context of this session? Regards, Shyam On Fri, Sep 18, 2020 at 1:12 AM Steve French <smfrench@gmail.com> wrote: > > In cases where we know the host name it makes sense to use that. But if they specify up address in unc name we will have to use that > > On Thu, Sep 17, 2020, 02:35 Aurélien Aptel <aaptel@suse.com> wrote: >> >> Aurélien Aptel <aaptel@suse.com> writes: >> > Shyam Prasad N <nspmangalore@gmail.com> writes: >> >> 1. For ntlmssp, I see that the credentials are stored in the keyring >> >> with IPv4 or IPv6 address as the key. Suppose the mount was initially >> >> done using hostname, and IP address changes (more likely in Azure >> >> scenario), we may end up looking for credentials with the wrong key. >> > >> > Yes I thought the same thing.. I'm not sure why the decision to use IP >> > was made. >> >> I suspect this code predates the existence of the in-kernel DNS >> resolver. Just a guess. >> >> Cheers, >> -- >> Aurélien Aptel / SUSE Labs Samba Team >> GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 >> SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE >> GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München) -- -Shyam ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: mutiuser request_key in both ntlmssp and krb5 2020-09-21 4:23 ` Shyam Prasad N @ 2020-09-21 9:31 ` Aurélien Aptel 2020-09-21 9:49 ` Aurélien Aptel 0 siblings, 1 reply; 6+ messages in thread From: Aurélien Aptel @ 2020-09-21 9:31 UTC (permalink / raw) To: Shyam Prasad N, Steve French; +Cc: Pavel Shilovsky, Paulo Alcantara, CIFS Hey, Shyam Prasad N <nspmangalore@gmail.com> writes: >> IIRC the keyring used is the session one, so each user gets a different keyring. > > Ah, I see. So I'm wondering how the multiuser mounts for ntlmssp work? > On each login, does the user have to populate the keyring with his/her > credentials? I think that was the idea yes, or maybe integrate with PAM somehow? But you'll have to do some archeological work with Jeff Layton to get to the bottom of this :) > Agreed for majority cases. But Steve makes a good point that this only > gets us the local uid/username. > However, the actual domain user name could be very different. For > example, local user user1 could be logged in as domain1\user1 or > domain2\user1. How do we handle this scenario? This is a sadistic puzzle game with many pieces... If the Linux client is properly integrated with AD ({winbind or ssd} + PAM module + nsswitch conf), you login with your AD user and get an AD uid. There is no local user. $ ssh 'NUC\administrator@192.168.122.50' Password: Last login: Mon Sep 21 10:41:34 2020 from 192.168.122.1 Have a lot of fun... NUC\administrator@twmember:~> id uid=20501(NUC\administrator) gid=20514(NUC\domain users) groups=20514(NUC\domain users),10000(BUILTIN\administrators),10001(BUILTIN\users),20501(NUC\administrator),20513(NUC\domain admins),20519(NUC\schema admins),20520(NUC\enterprise admins),20521(NUC\group policy creator owners),20573(NUC\denied rodc password replication group),21108(NUC\netmon users) $ mount.cifs //adnuc.nuc.test/data /x -o sec=krb5i,multiuser,cifsacl,username=administrator,domain=NUC $ ls -l /x -rwx------ 1 NUC\user1 NUC\domain users 0 Aug 5 22:14 from_u1 -rwx------ 1 NUC\user2 NUC\domain users 0 Aug 5 22:16 from_u2 I don't know what is the situation at Redhat but at SUSE the only supported way to use multiuser mounts (if even documented) is via a properly AD-joined system and kerberos. Even then, I think I've only seen 1 ticket from a multiuser setup in 5 years. Most setups are 1 mount per user for user dirs, where it makes sense to have everything owned by the user. > I'm guessing (please correct me if I'm wrong here) that an user > session corresponds to only one of those two remote users > (domain1\user1 or domain2\user1). In that case, how do we get the > fully qualified name in the context of this session? At the SMB level you only see Windows SIDs and cifs.ko will report all files as being owned by the mounter's uid (or uid= mount opt). When you mount with cifsacl mount option, cifs.ko will try to map those SIDs to uids by upcalling cifs.idmap. This program will ultimately query winbind or sssd to get the mapping. So userspace tools will see AD uids. Now to get the text username from it they use regular POSIX libc calls like getpwuid(). If your system is properly integrated with AD, this call gets rerouted via nsswitch to again use winbind/sssd. There is a book that covers some of this called "Mechanics of User Identification and Authentication: Fundamentals of Identify Management". It's from 2007 but still relevant. Here's a diagram from page 96: https://i.imgur.com/PBwXIuJ.png Glibc: https://www.gnu.org/software/libc/manual/html_node/Lookup-User.html Nsswitch: allows to replace the various traditional text-based databases of the system (/etc/passwd, /etc/hosts, ....) by calling into different backends. https://man7.org/linux/man-pages/man5/nsswitch.conf.5.html nsswitch winbind backend: https://gitlab.com/samba-team/samba/-/blob/master/nsswitch/winbind_nss_linux.c cifs.idmap plugin API: https://github.com/piastry/cifs-utils/blob/master/idmap_plugin.h cifs.idmap winbind backend (ships with cifs-utils): https://github.com/piastry/cifs-utils/blob/master/idmapwb.c cifs.idmap sssd backend (ships with sssd): https://github.com/SSSD/sssd/blob/12f74f8c98fac6a7eeb3937f623949bcb3adb547/src/lib/cifs_idmap_sss/cifs_idmap_sss.c Cheers, -- Aurélien Aptel / SUSE Labs Samba Team GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: mutiuser request_key in both ntlmssp and krb5 2020-09-21 9:31 ` Aurélien Aptel @ 2020-09-21 9:49 ` Aurélien Aptel 0 siblings, 0 replies; 6+ messages in thread From: Aurélien Aptel @ 2020-09-21 9:49 UTC (permalink / raw) To: Shyam Prasad N, Steve French; +Cc: Pavel Shilovsky, Paulo Alcantara, CIFS Aurélien Aptel <aaptel@suse.com> writes: >> Ah, I see. So I'm wondering how the multiuser mounts for ntlmssp work? >> On each login, does the user have to populate the keyring with his/her >> credentials? > > I think that was the idea yes, or maybe integrate with PAM somehow? But > you'll have to do some archeological work with Jeff Layton to get to the > bottom of this :) If you were asking *how* can the user populate it at this moment, then the answer is with the cifscreds program. But I don't know what was the planned scenario for users (login once, then manually call cifscreds a to login a 2nd time?) https://github.com/piastry/cifs-utils/blob/master/cifscreds.c Cheers, -- Aurélien Aptel / SUSE Labs Samba Team GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München) ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-09-21 9:49 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-17 2:07 mutiuser request_key in both ntlmssp and krb5 Shyam Prasad N
2020-09-17 9:23 ` Aurélien Aptel
2020-09-17 9:35 ` Aurélien Aptel
[not found] ` <CAH2r5muiYZGr=1rZHobpKXAtG+OCDORZok_acOkL6TQssVrm3Q@mail.gmail.com>
2020-09-21 4:23 ` Shyam Prasad N
2020-09-21 9:31 ` Aurélien Aptel
2020-09-21 9:49 ` Aurélien Aptel
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.