On Wed, Jan 11, 2017 at 6:17 AM, Sachin Prabhu <sprabhu@xxxxxxxxxx> wrote:
[snip]
> My own opinion is that when a mount option is explicitly passed, it is
> expected the option provided be used and fail if it cannot be used. I
> think replacing a explicitly requested mount option with another can
> lead to unexpected results and may also affect things activities like
> testing.
>
> There are other mount options like "vers=" where cifs doesn't attempt
> to replace an invalid protocol version with another. This in my opinion
> is the correct behaviour.
Allow me to play Devil's advocate, but with a bridge we'll have to
cross if we enact this behavior... Quoth The (current-ish) Fine Manual
page for mount.cifs (quoted in full for historical mail list
reference) :
"
sec=
Security mode. Allowed values are:
· none - attempt to connection as a null user (no name)
· krb5 - Use Kerberos version 5 authentication
· krb5i - Use Kerberos authentication and forcibly enable
packet signing
· ntlm - Use NTLM password hashing
· ntlmi - Use NTLM password hashing and force packet signing
· ntlmv2 - Use NTLMv2 password hashing
· ntlmv2i - Use NTLMv2 password hashing and force packet signing
· ntlmssp - Use NTLMv2 password hashing encapsulated in
Raw NTLMSSP message
· ntlmsspi - Use NTLMv2 password hashing encapsulated in
Raw NTLMSSP message, and force packet signing
The default in mainline kernel versions prior to v3.8 was
sec=ntlm. In v3.8, the default was changed to sec=ntlmssp.
If the server requires signing during protocol negotiation,
then it may be enabled automatically. Packet signing may also be
enabled
automatically if it's enabled in /proc/fs/cifs/SecurityFlags.
"
What is the defined behavior if I specify that I'd like any of the
more current NTLM variants kerberos-5, explicitly, without packet
signing but the server requires packet signing? Currently, we
silently turn it on. Is the defined behavior to now loudly fail
rather than enable signing? Especially since the default value
changed in Linux-3.8. I'd argue that we already somewhat treat the
"sec" option as a preference rather than a requirement. I would
further argue, although not strongly, that if we want to go down this
road, that we should accept multiple options and if NONE of them can
be used, then we fail. Does anyone have a better idea, or is the
consensus that this isn't as large of an issue (both technologically
and from a user perspective) as I perceive it to be?
Steve, I'll defer to you as well with my objection above noted.
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
