All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aurélien Aptel" <aaptel@suse.com>
To: Shyam Prasad N <nspmangalore@gmail.com>,
	Steve French <smfrench@gmail.com>,
	Pavel Shilovsky <piastryyy@gmail.com>,
	Paulo Alcantara <pc@cjr.nz>, CIFS <linux-cifs@vger.kernel.org>
Subject: Re: mutiuser request_key in both ntlmssp and krb5
Date: Thu, 17 Sep 2020 11:23:15 +0200	[thread overview]
Message-ID: <87tuvwlpto.fsf@suse.com> (raw)
In-Reply-To: <CANT5p=qTXPkjqBuR9cvwQoRZFb72gY4M22tMG5Q_1XC9vvKZcg@mail.gmail.com>

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)

  reply	other threads:[~2020-09-17  9:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-17  2:07 mutiuser request_key in both ntlmssp and krb5 Shyam Prasad N
2020-09-17  9:23 ` Aurélien Aptel [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tuvwlpto.fsf@suse.com \
    --to=aaptel@suse.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=nspmangalore@gmail.com \
    --cc=pc@cjr.nz \
    --cc=piastryyy@gmail.com \
    --cc=smfrench@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
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.