SMBC_parse_path doesn't seem to handle special characters

SATOH Fumiyasu fumiyas at osstech.jp
Tue Jan 26 06:22:04 MST 2010


At Mon, 25 Jan 2010 10:52:32 -0600,
Eduardo Kienetz wrote:
> > True. But then to cover that 100% we need a proper escaping
> > mechanism, something like quoted-printable or base64-encoded
> > utf8 (like LDAP does) that fits into the url scheme.
> >
> 
> Oh, you mean we should require the password to be base64 encoded? Doesn't
> seem that good since it still might return / in it (unless we use modified
> versions).

I think we must require the username and the password to be
URI-encoded (RFC 2396, RFC 2732), and libsmbclient must
require the URI-encoded username/password to be URI-decoded.

e.g.: smb://user:p%40ss%2Fword%5C%40m@serv@r/m@share/m@filename.txt

-- 
-- Name: SATOH Fumiyasu (fumiyas @ osstech co jp)
-- Business Home: http://www.OSSTech.co.jp/
-- Personal Home: http://www.SFO.jp/blog/

> I think what would solve our problem once and for all is to require escaping
> the @s that are part of the password. That would also eliminate the need for
> my first patch.
> e.g.: smb://user:p\@ss/word\\@m@serv@r/m@share/m@filename.txt
> In this case we'd have:
> 1) password (the backslah right before the @ was for escaping): p at ss/word\@m
> 2) server: serv at r
> 3) share: m at share
> ...
> 
> This way we'd look for the first : (indicating a password separator,
> usernames can't contain :), then just look for the next unescaped @ (server
> separator).
> 
> The reason I'm a bit reluctant to put in your patch directly
> > is the fact that I personally are always scared by
> > string-parsing. This code is already very hard to
> > understand for me.
> >
> 
> Well, it's quite simple though, but it'll not be needed once I use the
> escaping idea from above :)
> Hold on tight.
> 
> 
> > > P.S.: it looks like I'll have to create a
> > > "get_last_token_no_ltrim_talloc()", so that I can use at libsmb_path.c
> > > instead of next_token_no_ltrim_talloc(ctx, &p, &userinfo, "@"). That's to
> > > support parsing URLs with passwords containing @ (clarifying what I said
> > in
> > > my first e-mail).
> >
> > Hehe, that kindof supports my statement "string parsing is
> > scary", doesn't it? :-)
> >
> 
> Indeed, but I realized it wouldn't really help since server name, share name
> and file/folder can contain @.
> I'm glad I realized backslashing the @s in the password would be enough to
> solve everything, if I didn't miss anything, as it seems to me :)
> 
> Hold on, will submit it asap.
> 
> Eduardo Bacchi Kienetz


More information about the samba-technical mailing list