Re: [PATCH] cifs: Assume passwords are encoded according to iocharset (try #2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Oct 20, 2011 at 3:51 PM, Oskar Liljeblad <oskar@xxxxxxxxxxx> wrote:
> 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 op8

I think more than utf8 or ucs2, it is whether a character can even
if converted to unicode i.e. if my current code page does not have
that character, char2uni of that code page is going to return an
error so there is no question of ucs2 or utf8.

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


[Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux