On Mon, Feb 19, 2024 at 4:29 AM Steve French <smfrench@xxxxxxxxx> wrote: > > Updated the patch to allow remount to only change the password if > disconnected and the session fails to reconnect due to continued > access denied or password expired errors. > > Any thoughts on whether I should add another patch to throttle > repeated session setups after access denied or key expired (currently > looks like repeated every few seconds) maybe double the time > repeatedly (e.g. until a max of 10 or 20 or 30 seconds? between > reconnect attempts) instead of every two seconds. > > On Fri, Feb 16, 2024 at 8:41 AM Paulo Alcantara <pc@xxxxxxxxxxxxx> wrote: > > > > Shyam Prasad N <nspmangalore@xxxxxxxxx> writes: > > > > > need_recon would also be true in other cases, for example when the > > > network is temporarily disconnected. This patch will allow changing of > > > password even then. > > > We could setup a special flag when the server returns a > > > STATUS_LOGON_FAILURE for SessionSetup. We can make the check for that > > > flag and then allow password change on remount. > > > > Yes. Allowing password change over remount simply because network is > > disconnected is not a good idea. The user could mistype the password > > when performing a remount and then everything would stop working. > > > > Not to mention that this patch is only handling a specfic case where a > > mount would have a single SMB session, which isn't true for a DFS mount. > > > > > Another option is to extend the multiuser keyring mechanism for single > > > user use case as well, and use that for password update. > > > Ideally, we should be able to setup multiple passwords in that keyring > > > and iterate through them once to see if SessionSetup goes through. > > > > Yes, sounds like the best approach so far. It would allow users to > > update their passwords in keyring and sysadmins could drop existing SMB > > sessions from server side and then the client would reconnect by using > > new password from keyring. This wouldn't even require a remount. > > > > Besides, marking this for -stable makes no sense. > > > > -- > Thanks, > > Steve No major objections for this patch. While it may not cover all cases like DFS, multiuser etc., it's still a starting point to allowing users to change password on existing mounts without unmounting. Steve: We may want to check additionally that sec_type is not Kerberos for this remount. I also think that we should have a future patch to update passwords using cifscreds utility even for single user mounts. -- Regards, Shyam
