On Thu, Oct 20, 2011 at 3:30 PM, Jeff Layton <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thu, 20 Oct 2011 14:29:25 -0500 > Steve French <[email protected]> wrote: > >> On Thu, Oct 20, 2011 at 2:13 PM, Jeff Layton <[email protected]> wrote: >> > On Thu, 20 Oct 2011 13:21:59 -0500 >> > [email protected] wrote: >> > >> >> From: Shirish Pargaonkar <[email protected]> >> >> >> >> >> >> 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 <[email protected]> >> >> Signed-off-by: Shirish Pargaonkar <[email protected]> >> >> Tested-by: A <[email protected]> >> > >> > >> > 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? >> >> that is an interesting point - but if we do pass a new optional type >> of password blob down, we will have to make sure to overwrite/clear it >> carefully. >> >> > > I don't think this requires any kernel changes. Just have the kernel > treat the password as opaque like it does today. > > Again, I'm not saying this for certain. Maybe this patch makes the most > sense after all. But, I think we need some justification before we just > assume that decoding it according to the iocharset is the right thing > to do here. > > - -- > Jeff Layton <[email protected]> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.18 (GNU/Linux) >
I think this patch is good enough. I set these two different passwords on the Samba server alþizô 隶书 and both the times, with utf8 as a codepage on the client, mount succeeded. It appears that the default utf8 codepage, has large enough (perhaps all of Unicode's repertoir) to convert a character to unicode. mount -t cifs //server/share /mnt/smb_b -o iocharset=utf8,user=root%alþizô mount -t cifs //server/share /mnt/smb_b -o iocharset=utf8,user=root%隶书 I did not have to specify iocharset. Regards, Shirish -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
