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