[Bf-committers] [PATCH] Patch to storage.c to avoid crash on long userids

[Jochen Schmitt]

Am 29.03.2010 11:43, schrieb Rob M:
> Hi,
>
> The patch is bad style. You should not pass literal sizes to strncpy - what
> happens when someone changes the size of the array?
> Passing sizeof(files[num].owner) is better (but doesn't allow easy
> translation from 8bit chars to wide chars).
> Would it not also be better to increase the size of the owner field as well
> as not overflowing the array?
>
>   
Thank you for your feedback. You have right that I should use
sizeof(...) instead
of a literal constant to get more flexible for the case when the
definition of
the owner member may been changed.

For an increasement of the owner field, it may be necessary to know a
maximum
length which an userid may have. Unfportunately, I doesn't know any
limitation for it.

At last as far as I know the getpwent() function only returns 8bit data,
so a discussion
of translation to 16bit char is more theoratical, because in this case
we have to call
a special function to do this translation.

An inproved version of the patch you may find at the end of this mail.

Best Regards:

Jochen Schmitt

diff -up blender/source/blender/blenlib/intern/storage.c.uid
blender/source/blender/blenlib/intern/storage.c
--- blender/source/blender/blenlib/intern/storage.c.uid    2010-03-28
19:18:49.511022187 +0200
+++ blender/source/blender/blenlib/intern/storage.c    2010-03-29
15:51:00.164136396 +0200
@@ -331,7 +331,8 @@ void BLI_adddirstrings()
             struct passwd *pwuser;
             pwuser = getpwuid(files[num].s.st_uid);
             if ( pwuser ) {
-            strcpy(files[num].owner, pwuser->pw_name);
+              strncpy(files[num].owner, pwuser->pw_name,
sizeof(files(num].owner)-1);
+              files[num].owner[sizeof(files{num].owner)-1] = '\0';
             } else {
                 sprintf(files[num].owner, "%d", files[num].s.st_uid);
             }