[PATCH] cifs-utils: Correct max string lengths

[Jeff Layton]

On Fri, 19 Jul 2013 22:44:22 -0400
Scott Lovenberg <scott.lovenberg at gmail.com> wrote:

> On Jul 19, 2013, at 22:34, Steve French <smfrench at gmail.com> wrote:
> 
> > Leaving Max share length at 256 is fine with me
> > 
> Works for me. Should this be fixed kernel side?
> 

Yes, I think that would make sense. Scott, I assume you'll send a v2 of
this patch that preserves the share length at 256?

Once that's done, the ideal thing here would be to move these
definitions in the kernel to a separate header file that lives under
include/linux. Then we could have autoconf in cifs-utils look for that
header and use the #defines from that instead if it's present.

That way we won't be so reliant on keeping the kernel and cifs-utils in
sync...

> > On Jul 19, 2013 5:20 PM, "Scott Lovenberg" <scott.lovenberg at gmail.com> wrote:
> >> On Jul 19, 2013, at 17:51, Steve French <smfrench at gmail.com> wrote:
> >> 
> >> > MAX_SHARE_NAME of 80 is not correct.  I verified that Samba supports
> >> > much longer (see below), but also found some hits on other servers
> >> > with longer limits when searching for this.   Windows CLI does appear
> >> > to limit to 80 only in the NET SHARE command (also note that maximum
> >> > UNC path is probably limited by MAX_PATH to 32768 characters)
> >> 
> >> That appears to be correct. The full length of the path is the ultimate limit.  How would you like to handle this?
> >> 
> >> >
> >> > On Fri, Jul 19, 2013 at 4:26 PM,  <scott.lovenberg at gmail.com> wrote:
> >> >> From: Scott Lovenberg <scott.lovenberg at gmail.com>
> >> >>
> >> >> The max size of the username, domain, password and share name strings
> >> >> are now consistent with the kernel and Microsoft's documentation.
> >> >>
> >> >> Signed-off-by: Scott Lovenberg <scott.lovenberg at gmail.com>
> >> >> ---
> >> >> AUTHORS      |  2 ++
> >> >> mount.cifs.c | 27 ++++++++++++++++++---------
> >> >> 2 files changed, 20 insertions(+), 9 deletions(-)
> >> >>
> >> >> diff --git a/AUTHORS b/AUTHORS
> >> >> index 2807079..2f6a14d 100644
> >> >> --- a/AUTHORS
> >> >> +++ b/AUTHORS
> >> >> @@ -5,5 +5,7 @@ Shirish Pargaonkar <shirishpargaonkar at gmail.com>
> >> >> Suresh Jayaraman <sjayaraman at suse.de>
> >> >> Pavel Shilovsky <piastry at etersoft.ru>
> >> >> Igor Druzhinin <jaxbrigs at gmail.com>
> >> >> +Scott Lovenberg <scott.lovenberg at gmail.com>
> >> >> +
> >> >>
> >> >> ...and others.
> >> >> diff --git a/mount.cifs.c b/mount.cifs.c
> >> >> index 3b2b89e..8d975b3 100644
> >> >> --- a/mount.cifs.c
> >> >> +++ b/mount.cifs.c
> >> >> @@ -83,22 +83,31 @@
> >> >> /* max length of mtab options */
> >> >> #define MTAB_OPTIONS_LEN 220
> >> >>
> >> >> -/*
> >> >> - * Maximum length of "share" portion of a UNC. I have no idea if this is at
> >> >> - * all valid. According to MSDN, the typical max length of any component is
> >> >> - * 255, so use that here.
> >> >> +/*
> >> >> + * Max share name, username, password and domain sizes match the kernel's
> >> >> + * allowances for these string sizes which in turn match Microsoft's
> >> >> + * documentation.
> >> >>  */
> >> >> -#define MAX_SHARE_LEN 256
> >> >>
> >> >> -/* max length of username (somewhat made up here) */
> >> >> -#define MAX_USERNAME_SIZE 32
> >> >> +/* Max length of the share name portion of a UNC.  According to Microsoft
> >> >> + * this is correct for Windows 2000/XP. */
> >> >> +#define MAX_SHARE_LEN 80
> >> >> +
> >> >> +/* Max user name length. */
> >> >> +#define MAX_USERNAME_SIZE 256
> >> >> +
> >> >> +/* Max domain size. */
> >> >> +#define MAX_DOMAIN_SIZE 256
> >> >> +
> >> >> +/* Max password size. */
> >> >> +#define MOUNT_PASSWD_SIZE 512
> >> >> +
> >> >> +
> >> >>
> >> >> #ifndef SAFE_FREE
> >> >> #define SAFE_FREE(x) do { if ((x) != NULL) {free(x); x = NULL; } } while (0)
> >> >> #endif
> >> >>
> >> >> -#define MOUNT_PASSWD_SIZE 128
> >> >> -#define MAX_DOMAIN_SIZE 64
> >> >>
> >> >> /*
> >> >>  * mount.cifs has been the subject of many "security" bugs that have arisen
> >> >> --
> >> >> 1.8.1.4
> >> >
> >> >
> >> >
> >> > --
> >> > Thanks,
> >> >
> >> > Steve


-- 
Jeff Layton <jlayton at redhat.com>