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@xxxxxxxx> wrote: > > Shyam Prasad N <nspmangalore@xxxxxxxxx> 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
Attachment:
0001-mount.cifs-Have-an-option-to-authenticate-against-PA.patch
Description: Binary data
