-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 20 Oct 2011 14:29:25 -0500
Steve French <smfrench@xxxxxxxxx> wrote:
> 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?
>
> 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 <jlayton@xxxxxxxxx>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQIcBAEBAgAGBQJOoITXAAoJEAAOaEEZVoIVg6UP/0Z6BFlv2/UgVS3pVnMLmFHh
FJLLxHaHP+PRaNulx5WdJTM5rUCZDbtZOG1TQjsBKHiJwoBxxJr8Wpyas5SNtmuA
cp0oSjKilnZkykuoq+IcNuGywE/AbVh2HWBkwCi7JPWW0EHt+U8BVIfNbDpbOpPj
wZhE/ybDouWTs9Cq0V3Mi3VFwyqpVdR/hJtb8IT6YMGOg+IXs4V5lXiDNw1ENdSu
xKz8ESsfzeBhjAfcx+t5XAXteUGayIPXURQzy23NjF1bUcvqpvnG2WHS9vyEQnQS
lt4/ImR47sliIf8nuRe0VUM/F8XwZuRgXT9sWy9EMdoIVP1PpoMadyb2DsyYuvb1
zhbt4MN+eODjVSJyBMXYqJLBoAJ7PL8cfohb5oYYDMov4g9w+AtuAcLJSxgkKPmU
+X/OEYyHL9Tozq5s/ApZEq/dr6rnsBIPMqqg/fCmG5cqcTxw+c9c5qIBLchLa+vj
jBlG2MkNgeUOf9LvP/r58UhDBszUYSWsxspLLdoj5QeBG4skgxl182+foPvzobHo
RTtDkn9mn5e9+/DqYdCLBYRLxsyptlA/47DnevB3BSrun1LcXalPiNOcqUMjuVzK
+xLYh3gfGfZKIFuOFAfKDQ89oPjZT21AOWyt4J+Di5/pJCDVB/S3qXvxoOlj9zvT
dqLM5pUwEpq830oCxPlB
=XyQR
-----END PGP SIGNATURE-----
��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
