On Thursday, October 20, 2011 at 16:06, Jeff Layton wrote: [..] > > > 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. I like the idea of opaque passwords as well, but the problem is that the password needs to be in UCS-2 for smb. The password is passed through _my_mbstowcs which converts the 8-bit password to 16-bit UCS-2 simply by setting high byte to zero. So that makes opaque 8-bit passwords impossible. One alternative would be to assume passwords in UTF-8 regardless of iocharset. Regards, Oskar -- 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
