openssh unix dev - May 2017 - Bug? unnecessarily constrained lengths in path, filename, and user

in misc.c, tilde_expand_filename() PATH_MAX is used. However in readconf.c path
and filename components are arbitrarily set to 100 and 100 during the
xasprintf() as part of add_identity_file() instead of using NAME_MAX and
PATH_MAX.

  (void)xasprintf(&path, "%.100s%.100s", dir, filename);

Also I think it's reasonable that a message should be logged if the input
was truncated.

Now, I'm not sure what the knock-on effects are from a portable-edition
standpoint, but I believe most libC implementations have the same or similar
constants that can be utilized.


In the same vein, misc.c, tilde_expand_filename()
  char user[128]

Granted this is probably a case of sized so big,nobody will hit it. But why not
actually leverage the OS' definitions? Or are these limits not easily found?
In linux I believe it's 32 char but so far I haven't found the
definition in either kernel source nor glibc.

On Thu, 18 May 2017, matthew patton wrote:
> in misc.c, tilde_expand_filename() PATH_MAX is used. However in
> readconf.c path and filename components are arbitrarily set to 100 and
> 100 during the xasprintf() as part of add_identity_file() instead of
> using NAME_MAX and PATH_MAX.
>
>   (void)xasprintf(&path, "%.100s%.100s", dir, filename);
>
> Also I think it's reasonable that a message should be logged if the
> input was truncated.
Thanks, I've replaced the limit with a check that the result doesn't
exceed PATH_MAX.
> In the same vein, misc.c, tilde_expand_filename() char user[128]
>
> Granted this is probably a case of sized so big,nobody will hit it.
> But why not actually leverage the OS' definitions? Or are these limits
> not easily found? In linux I believe it's 32 char but so far I
haven't
> found the definition in either kernel source nor glibc.
IIRC some systems lacked an accessible LOGIN_NAME_MAX and
_POSIX_LOGIN_NAME_MAX only provides a lower bound.

-d