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

[Shyam Prasad N]

I did some code reading on samba-winbind (and sssd to some extent),
and here are a few things I noticed.
1. Both today have almost "no-op" handlers for open and close of PAM sessions.
2. However, the login and logoff do have some functionalities. PAM
setcred is done both on log-on and log-off, so that the cred cache is
deleted on the last logoff.
3. Login and logoff have ref counts associated with a user. But I do
notice that a kinit is done on every login (even if the user is
already logged on).

So it looks like (at least as of today) we don't break much by
authenticating with PAM. One additional change needed would be to
introduce umount.cifs, which deletes PAM credentials for the user.

Alternatively, another option is to not rely on winbind/sssd for
authentication (or maintaining krb5 tgt up-to-date), but instead let
cifs-utils deal with it separately. Today, cifs.upcall has a way to
kinit if the cred cache file is missing. But that needs the keytab
file to be populated with the key for the user in question. We could
also try a kinit based on password in mount.cifs (if the cred cache is
missing), and if that works, populate the keytab file with the key for
this user (for cifs.upcall to use later, when necessary).

Thoughts?

Regards,
Shyam

On Mon, Aug 17, 2020 at 2:42 PM Shyam Prasad N <nspmangalore at gmail.com> wrote:
>
> Thanks Aurélien. Good points.
> Let me take a closer look at this and see how to proceed.
>
> Regards,
> Shyam
>
> On Mon, Aug 17, 2020, 14:18 Aurélien Aptel <aaptel at suse.com> wrote:
>>
>> Shyam Prasad N <nspmangalore at gmail.com> writes:
>> > 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.
>>
>> When reconnecting or accessing DFS links (cross-server symlinks) the
>> client opens a new connection to the target server and has to auth
>> again. Since there are no ways to ask for a password at that moment
>> (we're in the middle of some syscall) cifs.ko does an upcall to
>> cifs.upcall and passes the pid of the process who initiated the
>> syscall. cifs.upcall then reads that proc env (via /proc/<pid>/environ)
>> and looks for KRB5CCNAME, uses it and returns the required data for
>> cifs.ko to proceed with the SMB Session Setup.
>>
>> So it is important to have this env var set if the location of the
>> credential cache is not the default one. If you do PAM login from
>> mount.cifs, the env var might be set for that process but it will only
>> persist in children processes of mount.cifs i.e. most likely none.
>>
>> I still think this patch is a good idea but we should definitely print
>> something to the user that things might fail later on, or give
>> instructions to set the env var in the user shell or something like that.
>>
>> > 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.
>>
>> Mount option sounds good regardless.
>>
>> > 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.
>>
>> The keyring docs have some info on it too but it's still not clear to
>> me.
>>
>> https://man7.org/linux/man-pages/man7/session-keyring.7.html
>>
>> 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