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@xxxxxxxxx> 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@xxxxxxxx> wrote: >> >> Aurélien Aptel <aaptel@xxxxxxxx> writes: >> > Shyam Prasad N <nspmangalore@xxxxxxxxx> 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
