On Thu, 13 Dec 2001, H VC wrote:
> I have noticed that it only seems to work whe I parse a user string to
> su near the limit ( free mem. + swap ). Over this range is detected as
> a too many large string but also just over the available memory...
a quick perusal through the su.c source code in that SRPM reveals a likely
culprit: the function 'concat':
190 /* Return a newly-allocated string whose contents concatenate
191 those of S1, S2, S3. */
192
193 static char *
194 concat (const char *s1, const char *s2, const char *s3)
195 {
196 int len1 = strlen (s1), len2 = strlen (s2), len3 = strlen (s3);
197 char *result = (char *) xmalloc (len1 + len2 + len3 + 1);
198
199 strcpy (result, s1);
200 strcpy (result + len1, s2);
201 strcpy (result + len1 + len2, s3);
202 result[len1 + len2 + len3] = 0;
203
204 return result;
205 }
basically the code happily xmalloc's the proper length argument to prevent
an overflow, but doesn't do ANY sanity checking on lengths ...
> Why su allows so large user names ?
> How long could be a unix/linux user name ?
> Why do not su limit the size of username to the unix/linux max. size of a
> user name ?
these are perfectly valid questions, and they should definitely be fixed
in the implementation. chop it off at the MAX_LOGIN_NAME size ...
looks like good intentions gone horribly awry.
____________________________
jose nazario joseat_private
PGP: 89 B0 81 DA 5B FD 7E 00 99 C3 B2 CD 48 A0 07 80
PGP key ID 0xFD37F4E5 (pgp.mit.edu)
This archive was generated by hypermail 2b30 : Thu Dec 13 2001 - 09:33:06 PST