Re: specifying password when using krb5

["Aurélien Aptel" <aaptel@suse.com>]

Frank Loeffler <frank.loeffler@uni-jena.de> writes:
> 1. Is it intended that mount.cifs will not ask for a password when using 
> sec=krb5 and will ignore any set password?

As Shyam said, this seems to be the case.

> 2. I don't want to setup krb5-tokens for users. All I want is 
> authenticate using krb5 to get the smb-session and then forget about 
> krb5. smbclient seems to be able to do this. I don't know how they do 
> it, I suspect they create a temporary token, open the session, and then 
> drop it again. Whatever smbclient does: couldn't mount.cifs do the same 
> or something similar? This would make the 'password' setting meaningful 
> for sec=krb5. This does not mean that existing tokens couldn't and 
> shouldn't be used. It would just mean that users would not *have* to use 
> an external mechanism for this.

When you use a password you're actually not using krb5 (even in
smbclient), you're using NTLMSSP authentication.

> 3. For the moment (and only if my observations are correct): could the 
> documentation be updated to reflect that "password" is ignored for 
> "sec=krb5"? Users shouldn't need to dig inside the source code to find 
> out things like that.

That's a good point, I'll try to update the cifs-utils man page.

> 4. Currently, trying sec=krb5 without token cache files results in the 
> rather obscure error "mount error(2): No such file or directory". Could 
> this me changed into something that points users to the actual cause of 
> the error?

Sadly we don't have much to work with. Mounting is done with a single
system call mount() which can only return 1 error code from the list of errno
codes https://man7.org/linux/man-pages/man3/errno.3.html

The error printed is the generic description of those code stored in
your libc.

There is a new mount syscall API that allows returning errors _strings_
to userspace. I've sent experimental patches to make use of it but I
haven't received any feedback on it. Your post is a great example of why
we should merge it.

> 5. Am I even remotely correct with any of this? :)

I think you are :) thanks for reporting.

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)