Bug 2319 - smbspool doesn't decode %-encoded characters
Summary: smbspool doesn't decode %-encoded characters
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Client Tools (show other bugs)
Version: 3.0.12
Hardware: All All
: P3 major
Target Milestone: none
Assignee: Simo Sorce
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-07 08:07 UTC by Michael Sweet
Modified: 2007-06-16 13:55 UTC (History)
1 user (show)

See Also:


Attachments
Unescape URI components of the uri passed to smbspool (3.09 KB, patch)
2007-06-12 10:43 UTC, Simo Sorce
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Sweet 2005-02-07 08:07:29 UTC
This bug also applies to 3.x.

Basically, the current SMB schema does not conform to RFC 3986 (the current URI
specification) since the workgroup/domain is part of the userinfo.  Since the
"/" character is not an allowed character in this part of the URI, it must be
escaped (%2F), however the smbspool program doesn't do % decoding in the URI.

The crux of this problem is that CUPS tries to sanitize URIs to avoid publishing
authentication info, however unencoded SMB URIs can't be sanitized without us
special-casing smb: (which we don't want to do...)  We get reports of this "bug"
at least once a month, and while we tell users not to use smbspool unless it is
absolutely required, it would be nice to at least have a workaround so that they
aren't exposing their authentication info...

Sooo, the solution is to support % decoding in smbspool; normally, I'd just use
httpSeparate() (which handles it already), however I remember that you didn't
want to depend on CUPS just to compile this program.

I'll work on a patch, but I thought I'd file this issue so it is tracked and in
case you already have a URI decoding function in libsmbclient you can tell me
about... :)
Comment 1 Lars Müller 2005-02-21 07:18:13 UTC
http://ietfreport.isoc.org/idref/draft-crhertel-smb-url/ is the current SMB URI
draft.

Therefore a SMB URI to a printer should look like
smb://[workgroup;][user[:password]@]server/printername
Comment 2 Lars Müller 2005-02-22 03:51:37 UTC
There is no password in the SMB URI draft.
Comment 3 Michael Sweet 2005-02-22 06:17:10 UTC
Actually, the ABNF definition includes the userinfo_nosem rule which allows for
strings of the form user:pass, just as RFC 3986 does.

The authdomain portion from:

    smb://authdomain;user:pass@server/...

is NOT the same as the workgroup, but corresponds instead to the NT domain used
for authentication (they often have the same name, but that is not a requirement)

It appears that the current SMB URI spec does not include the workgroup in the
name resolution of a server, so I'm not sure how that will fit with SAMBA's
implementation of SMB/NMB...
Comment 4 Christophuzzy R. Hertel 2005-02-24 13:21:02 UTC
RFC 3986 is a new URI General Syntax document, which was recently published.  I
have already read through it a couple of times (when it was in draft form) and
will read it again before posting another SMB URI draft update.

That said...

In the earlier RFC 2396, the '\' character was listed as part of the "unwise"
set.  The semicolon (';'), in contrast, was given as a legitimate character in
the <userinfo> field.  In the newer RFC 3986, the semicolon is listed as a
sub-delimiter and also considered a valid <userinfo> character.  So...  It works.

You can't really use the '\' without escaping it, as in:
  smb://ntdom%5Cusrnam@svr/

In the above, however, the URI escape sequence can't be used as a URI delimiter,
so the above would be parsed as:

  username: ntdom\usrnam
    server: svr

The username would then be passed to the SMB implementation layer that is below
the URI parsing layer, and the SMB implementation could easily do its own parsing.

...but that's not how we decided to do it.

Since the '\' character is not a legitimate character in the <userinfo> field,
it woundn't really work to permit things like:

  smb://ntdom\usrnam@svr/
or
  smb://ntdom\\usrnam@svr/

Those don't conform to the general syntax of a URI.  That's why you have to use
"%5C".  The problem was that "%5C" is more annoying to type than ";" or "\;", so
we chose, instead to allow the SMB URI parser to handle separating the
authentication domain from the username.

As for the use of the colon (':') for password entry...  The folks on the W3C's
URI mailing list strongly dislike the use of the colon to permit the entry of
the password as part of the URI string.  On the other hand, everyone does it.
The colon is also a legitimate delimiter.

The strong recommendations would be:
1) Users should not enter a password as part of the URI string.
2) User agents should remove the password and redisplay the URI without it,
   if possible.
3) User agents should provide an alternate means of entering a password (a
   pop-up or prompt).

On the other hand...  There's a lot of good reason to support the :password
syntax.  It's use is wide-spread, after all, and there does need to be some
mechanism for supplying passwords in, for example, /etc/fstab (or
/etc/samba/smbfstab).

To some specifics:

  'Basically, the current SMB schema does not conform to RFC 3986 (the current
   URI specification) since the workgroup/domain is part of the userinfo.
   Since the "/" character is not an allowed character in this part of the
   URI, it must be escaped (%2F), however the smbspool program doesn't do %
   decoding in the URI.'

In the SMB URI, the workgroup/domain part is really the <auth_domain> field, and
it's purpose is to specify the NT (or AD) domain to which the user belongs.  It
doesn't have any impact on Network Neighborhood (workgroup) browsing.

The <auth_domain field is delimited from the username using a semicolon, not a
slash or backslash (for reasons given above).

I have no idea whether smbspool attempts to use correct SMB URI syntax or not.

  'Sooo, the solution is to support % decoding in smbspool; normally, I'd just
   use httpSeparate() (which handles it already), however I remember that you
   didn't want to depend on CUPS just to compile this program.'

URI escapes should be decoded only *after* the URI has been parsed into its
component pieces.  Delimiters can't be delimiters if they're URI escaped.

So, as outlined in the discussion...

  smb://[[authdomain;]username[:password]@]server[:port]/print_share

would be pretty dang close to correct syntax for specifying an SMB-shared print
service.

Chris -)-----
Comment 5 Michael Sweet 2005-02-24 14:28:29 UTC
Chris, you said:

    'URI escapes should be decoded only *after* the URI has been parsed into
     its component pieces.  Delimiters can't be delimiters if they're URI
     escaped.

     So, as outlined in the discussion...

       smb://[[authdomain;]username[:password]@]server[:port]/print_share

     would be pretty dang close to correct syntax for specifying an SMB-shared
     print service.'

I have no problem with the proposed (new) syntax, and just want smbspool to
support a single URI format.  FWIW, httpSeparate() does all the "right" things
WRT % escaping and delimiters, and the code is small and simple enough that I
have no problem contributing it to the Samba project so that smbspool works
properly... :)

So, I guess the real question is: will server lookups work without a workgroup
in general?  That used to be a problem when I first did smbspool, so before I go
ahead and code the changes needed, will it work? :)
Comment 6 Christophuzzy R. Hertel 2005-02-24 15:36:09 UTC
Michael Sweet wrote:

  'I have no problem with the proposed (new) syntax, and just want smbspool to
   support a single URI format.  FWIW, httpSeparate() does all the "right"
   things WRT % escaping and delimiters, and the code is small and simple
   enough that I have no problem contributing it to the Samba project so that
   smbspool works properly... :)'

I'm not familiar with any "proposed (new) syntax" for the SMB URI.  I've been
working on the drafts for years (several) and we've never proposed using the '\'
as a delimiter in any of the drafts.  It's been the semicolon for a long time
now.  Nothing "new" as far as I know...

  'So, I guess the real question is: will server lookups work without a
  workgroup in general?  That used to be a problem when I first did smbspool,
  so before I go ahead and code the changes needed, will it work? :)'

There is a different set of semantics for looking up servers that are members of
a workgroup.  Just quickly:

  smb://

is supposed to find all of the "locally known" workgroups.

  smb://workgroup/

is supposed to list all of the SMB servers that are members of the given
workgroup.  Note that the workgroup in the above string fits into the <server>
field, so something like this:

  smb://ntdom;user:passwd@workgroup/

is also legitimate.  In fact, it's needed for some servers that require
authentication to access the browse list.

The distinction between smb://workgroup/ and smb://smb_server/ is made
semantically.  You have to contact the server and find out what services it is
offering under those names.

So... back to your question:  will server lookups work without a workgroup in
general?

If you just want to find a server by name then you don't need to specify the
workgroup.  You only need the server name (which can be a NetBIOS name or a DNS
name).

If, however, you want to get a list of servers so that you can "browse" them
(see what services they're offering) you will probably want to start with at the
workgroup level:  smb://workgroup/.

The pseudo-hierarchy is this:

All workgroups (equivalent, more or less, to Windows' "Entire Network")
  |
  +-> A specific workgroup
        |
        +-> A server within the workgroup
              |
              +-> share offered by the server
                    |
                    +-> directory path, etc.

Does that answer the question?

Hope so!

Chris -)-----
Comment 7 Michael Sweet 2005-02-24 16:54:39 UTC
It is new in the sense that the smbspool program has, since I contributed it for
2.0.6, used the following formats:

    smb://[username[:password]@]server/printername
    smb://[username[:password]@]workgroup/server/printername

So what I am asking is an implementation question: will the SAMBA client
lookup/connection code work without the workgroup name?  If so, there should be
no problems using the SMB schema URL format instead.
Comment 8 Gerald (Jerry) Carter (dead mail address) 2005-03-21 19:38:11 UTC
why is this in trunk ?  SHould be 3.0
Comment 9 Benjamin Delagoutte 2006-08-28 09:16:41 UTC
As a matter of fact, this bug prevents from using password including '#' (sharp) character. The right way of escaping this character in CUPS is URLEncode : '%23'. However, smbspool don't decode %-encoded chars, and fails to authenticate.
Comment 10 Simo Sorce 2007-06-12 10:43:20 UTC
Created attachment 2748 [details]
Unescape URI components of the uri passed to smbspool

This patch should address the problem of passing charcters that should be escaped to smbspool as part of the uri.
My preliminary test show the uri components are escaped properly, please comment.
If good I'll commit
Comment 11 Simo Sorce 2007-06-16 13:55:10 UTC
A report tells me this is good.
Close it.
Committed r23524