Bug? unnecessarily constrained lengths in path, filename, and user

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



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.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev



[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux