I tried to use this as a fallback option, but there's an issue. During
the first mount attempt, cifs.upcall pushes the credentials lookup
failure to the keyring. So on the next attempt, request_key() doesn't
even call into the userspace, since there's already an entry there. So
we'll probably have to call it under a new child process on the
fallback attempt.

@Aurélien Aptel Do you think that it is worth the effort? or should we
just keep force_pam as a mount option?

Also, I'll test this out with DFS once I figure out how to set it up. :)
Re-attaching the patch with some minor changes with just the
"force_pam" mount option.

Regards,
Shyam

On Thu, Sep 10, 2020 at 3:13 PM Aurélien Aptel <aaptel@suse.com> wrote:
>
> Shyam Prasad N <nspmangalore@gmail.com> writes:
> > Your understanding is correct. We could also go for a hybrid approach,
> > where we fallback to option b when option a fails to authenticate.
> > But for now, I'll resubmit a patch with option a as a fallback when
> > regular mount fails, just like you had suggested.
>
> Please try DFS setups as well. On DFS links a sub-mount is made from the
> kernel and mount.cifs is not called.
>
> 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