1

When mounting a CIFS share using krbr5i and destroying my Kerberos tickets with kdestroy afterwards its still possible to mount other shares on the same server. How is this possible? Doesn't mount.cifs have to send the service ticket to the sharing server again? Is the ticket cached somewhere? Is this handled by the kernel (or cifs.upcall)?

After unmounting all shares mount.cifs will fail (as expected).

Steps to reproduce:

$ # Aquire tgt:
$ kinit
Password for sahisb@DOMAIN.EXAMPLE.COM:
$ # Mount share1 and get cifs ticket:
$ sudo mount.cifs -v -o sec=krb5i,cache=strict,rw,user=sahisb,cruid=$UID,cifsacl,nounix,multiuser,vers=2.1 //dc.domain.example.com/share1 /share1
mount.cifs kernel mount options: ip=[redacted],unc=\\dc.domain.example.com\share1,sec=krb5i,cache=strict,cifsacl,nounix,multiuser,vers=2.1,cruid=1297401199,user=sahisb,pass=********
$ # Destroy tgt and cifs ticket:
$ kdestroy
$ # Mount share2. I expected this to fail but it will succeed:
$ sudo mount.cifs -v -o sec=krb5i,cache=strict,rw,user=sahisb,cruid=$UID,cifsacl,nounix,multiuser,vers=2.1 //dc.domain.example.com/share2 /share2
mount.cifs kernel mount options: ip=[redacted],unc=\\dc.domain.example.com\share2,sec=krb5i,cache=strict,cifsacl,nounix,multiuser,vers=2.1,cruid=1297401199,user=sahisb,pass=********

At this point klist still cannot find a credentials cache. Now let's try to unmount the shares and mount them again:

$ umount /share1
$ umount /share2
$ sudo mount.cifs -v -o sec=krb5i,cache=strict,rw,user=sahisb,cruid=$UID,cifsacl,nounix,multiuser,vers=2.1 //dc.domain.example.com/share2 /share2
mount.cifs kernel mount options: ip=[redacted],unc=\\dc.domain.example.com\share2,sec=krb5i,cache=strict,cifsacl,nounix,multiuser,vers=2.1,cruid=1297401199,user=sahisb,pass=********
mount error(126): Required key not available

Which fails as expected.

sahisb
  • 31
  • 5

1 Answers1

2

When mounting a CIFS/SMB share a session is created (if the credentials - in this case a kerberos service ticket - to the service are correct). After a session is created we don't have to authenticate ourselves anymore.

Since share1 and share2 are provided by the same service (dc.domain.example.com) all requests to these files are using the same session.

sahisb
  • 31
  • 5