[PATCH][SMB3] mount.cifs integration with PAM

[Shyam Prasad N]

Hi Aurélien,

Thanks for the review. Please read my replies inline....

On Fri, Aug 14, 2020, 15:22 Aurélien Aptel <aaptel at suse.com> wrote:

> Hi Shyam,
>
> Shyam Prasad N <nspmangalore at gmail.com> writes:
> > Currently, for sec=krb5, mount.cifs assumes that the kerberos TGT is
> > already downloaded and stored in krb5 cred cache file. If an AD user
> > is logged in through ssh or su, those utilities authenticate with PAM
> > (winbind or sssd), and winbind/sssd can be configured to perform
> > krbtgt house-keeping (like refreshing the tickets). However, if the AD
> > user is not logged in, and the local root user wants to mount the
> > share using the credentials for an AD user, he/she will need to resort
> > to manual kinit, and this does not go through winbind/sssd.
>
> That is correct, I think. Note that using when login in the system PAM
> also sets up KRB5CCNAME variable that points to the credential cache
> (e.g. "FILE:/tmp/krb5cc_0") and is then inherited in all processes in
> the session.
>
Agreed. But since we're not dealing with krb5cc file directly in
mount.cifs, I don't see it influencing this change. However, I will test it
out too.

>
> > Attached patch will introduce PAM authentication in mount.cifs. If
> > sec=krb5 is specified, mount.cifs will attempt to authenticate with
> > PAM as the username mentioned in mount options. If the authentication
> > fails, we fall back to the old behavior and proceed with the mount
> > nevertheless.
>
> Shouldn't we do it the other way around? i.e. try to use any existing
> credential cache, and if that fails auth again with PAM. I think we
> might end up overwriting an existing cache or logging in twice
> otherwise.
>
That does make sense. I was thinking of including a mount option to enable
this path. But let me explore the retry-on-failure path as well.

>
> > @linux-cifs: Please review the overall flow, and let me know if there
> > are any issues/suggestions. The feature is enabled by default in a
> > configure parameter (krb5pam), and can be disabled. Do we also need a
> > new mount option to trigger this new behavior? (try-pam-auth?)
>
> > @samba-technical: Please review the overall flow of PAM
> > authentication. Currently, I'm mainly doing pam_authenticate and
> > pam_setcreds. Is there any added benefit opening and closing session?
> > Is it possible to call pam_open_session from mount.cifs, and then call
> > pam_close_session in another binary (umount.cifs)?
>
> I am not 100% sure about this but I think the session should be opened
> in the context of the parent shell process to be able to be persistent,
> otherwise the session will close when mount.cifs exits. Maybe there is a
> way to pin the session on a different processes... But most likely there
> is an existing session opened by PAM when the user initially logged in
> the system (regardless of the PAM backend/params).
>
Yeah. I didn't get the complete picture on session maintenance after
reading the pam application developer's guide.
Was hoping that somebody on samba-technical would have some idea about this.

>
> 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)
>