On Thu, Oct 20, 2011 at 3:58 PM, Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> wrote: > On Thu, Oct 20, 2011 at 2:13 PM, Jeff Layton <jlayton@xxxxxxxxx> wrote: >> On Thu, 20 Oct 2011 13:21:59 -0500 >> shirishpargaonkar@xxxxxxxxx wrote: >> >>> From: Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> >>> >>> >>> Re-posting a patch originally posted by Oskar Liljeblad after >>> rebasing on 3.2. >>> >>> >>> Modify cifs to assume that the supplied password is encoded according >>> to iocharset. Before this patch passwords would be treated as >>> raw 8-bit data, which made authentication with Unicode passwords impossible >>> (at least passwords with characters > 0xFF). >>> >>> The previous code would as a side effect accept passwords encoded with >>> ISO 8859-1, since Unicode < 0x100 basically is ISO 8859-1. Software which >>> relies on that will no longer support password chars > 0x7F unless it also >>> uses iocharset=iso8859-1. (mount.cifs does not care about the encoding so >>> it will work as expected.) >>> >>> Signed-off-by: Oskar Liljeblad <oskar@xxxxxxxxxxx> >>> Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> >>> Tested-by: A <nimbus1_03087@xxxxxxxxx> >> >> >> I don't know about this. What happens if I have characters in my >> password that are not part of the current iocharset? I guess I'm >> screwed? >> >> The iocharset (and on smbfs, the remotenls) really only referred to the >> encoding/decoding of filenames. What's the justification for assuming >> that the password ought to be governed by that as well? >> >> If you're mounting with a cred file, is it really correct to assume >> that it's encoded according to the local charset? It seems like if I >> have the password stored in a credential file that it ought to work >> even if I copy it to a host that uses a different iocharset for >> encoding and decoding filenames. >> >> Would it be better to have userspace encode the password instead so >> that you have some flexibility if it's impossible to encode your >> password in the current iocharset? >> >> -- >> Jeff Layton <jlayton@xxxxxxxxx> >> > > For a successful authentication, password blob at > the client, however generated, has to match the blob > that is used at the server in order to generate a > correct ntlm response. > > I think we ought to have a mount option that specifies the > codepage of the server. > > If my current codepage (e.g. the default of utf8) does not > a character (e.g. umlaut) that is part of the password at the > server and part of the codepage at the server, I will fail > authentication. > > The new mount options should state its purpose in the > man page i.e. its use is limited to password translation. > > Because password is used in calculating ntlm response, > we will have to have code value of a character as per the > codepage at the server to genereate correct hashes > and ntlm response blob in cifs module. > > But if the codepage on the client is different or smaller > subset of the codepage at the server, how would each > character of a password blob be identified/distinguished > in order to convert it to that belonging to the code page > at the server such that new blob is used during > ntlm response calculation? > > Regards, > > Shirish > Sorry, disregard my post. I got the fundamentals wrong. We need unicode password. Apologies. -- 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
