[linux-cifs-client] Can we trust the server to return proper signing capability on session setup

[Jeff Layton]

On Thu, 04 Oct 2007 15:13:52 -0500
"Steve French (smfltc)" <smfltc at us.ibm.com> wrote:

> If the Linux cifs client turns off signing (signing is available by 
> default), but the server requires it, the client still attempts session 
> setup.  Presumably the original reason for this was that we did not 
> trust the server to always get the flags right - and it does not hurt to 
> try to continue (if the server does not like getting unsigned packets it 
> will take the session down).   The cifs client does log a warning 
> message that signing was turned off (on the client) but the server 
> requires it, but the error on mount will be "Resouce Temporarily 
> Unavailable" (rc = -11) since the server session went away (the user 
> does not see a more intuitive error e.g. Operation Not Supported)
> 
> 1) What should the posix error be (EOPNOTSUPP is not strictly true, and 
> EACCESS is misleading) ?
> 

Hmm...EPERM maybe?

#define EPERM            1      /* Operation not permitted */

...though that doesn't seem quite right either...

#define ENOKEY          126     /* Required key not available */

I don't guess it matters too much really. The mount(2)
manpage doesn't list ENOKEY or EOPNOTSUPP as valid return codes (perhaps
that's just because no one has actually used them here though :-).

> 2) Should the client override the tconx error (-11) for this case or not 
> attempt tconx at all (when it would get EOPNOTSUPP presumably, but might 
> run into problems if the server screwed up the flags as we have seen 
> some do recently)

Good question. If the flags are sometimes wrong, then it's probably
best to actually attempt the connection. Do we know of any specific
servers that are broken in this way? It would be a good to have some
idea of how much breakage there would be if we made this change...

-- 
Jeff Layton <jlayton at redhat.com>