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 -- 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
