busybox-w32/libbb, branch 1_00

Make certain clients of bb_make_directory default to honoring

2004-10-13T06:25:52+00:00

the user's umask

Patch from Claus Klein to increase, and make more apparent

2004-10-08T08:57:35+00:00

the hard coded limit on the number of mounts

Tito writes:

2004-10-08T08:07:40+00:00

Hi to all, This patch contains just some fixes for some misleading comments in my_getpwuid.c and my_getug.c. The code is untouched so this patch will not cause troubles. Please apply. Thanks in advance and Ciao, Tito

egor duda writes:

2004-10-08T07:46:08+00:00

Hi! I've created a patch to busybox' build system to allow building it in separate tree in a manner similar to kbuild from kernel version 2.6. That is, one runs command like 'make O=/build/some/where/for/specific/target/and/options' and everything is built in this exact directory, provided that it exists. I understand that applyingc such invasive changes during 'release candidates' stage of development is at best unwise. So, i'm currently asking for comments about this patch, starting from whether such thing is needed at all to whether it coded properly. 'make check' should work now, and one make creates Makefile in build directory, so one can run 'make' in build directory after that. One possible caveat is that if we build in some directory other than source one, the source directory should be 'distclean'ed first. egor

Patch from Michael Tokarev:

2004-10-08T07:21:58+00:00

Scenario: touch x -- creates plain file name `x' mkdir x -- exits successefully libbb/make_directory.c, bb_make_directory(), contains the following code: if (mkdir(path, 0777) < 0) { /* If we failed for any other reason than the directory * already exists, output a diagnostic and return -1.*/ if (errno != EEXIST) { fail_msg = "create"; umask(mask); break; } /* Since the directory exists, don't attempt to change * permissions if it was the full target. Note that * this is not an error conditon. */ if (!c) { umask(mask); return 0; } } The assumption that EEXIST error is due to that the *directory* already exists is wrong: any file type with that name will cause this error to be returned. Proper way IMHO will be is to stat() the path and check whenever this is really a directory. Below (attached) is a patch to fix this issue.

Remove this error message at Vodz request, it was misleading.

2004-09-24T02:36:44+00:00

Tito writes,

2004-09-15T03:04:08+00:00

"This patch fixes all the bugs in id previously spotted by vodz and me. The binary size increased a bit, but now it should work as expected."

No longer needed

2004-09-02T23:11:53+00:00

Tito writes:

2004-09-02T22:21:41+00:00

Hi Erik, Hi to all, This is part five of the my_get*id story. I've tweaked a bit this two functions to make them more flexible, but this changes will not affect existing code. Now they work so: 1) my_getpwuid( char *user, uid_t uid, int bufsize) if bufsize is > 0 char *user cannot be set to NULL on success username is written on static allocated buffer on failure uid as string is written to buffer and NULL is returned if bufsize is = 0 char *user can be set to NULL on success username is returned on failure NULL is returned if bufsize is < 0 char *user can be set to NULL on success username is returned on failure an error message is printed and the program exits 2) 1) my_getgrgid( char *group, uid_t uid, int bufsize) if bufsize is > 0 char *group cannot be set to NULL on success groupname is written on static allocated buffer on failure gid as string is written to buffer and NULL is returned if bufsize is = 0 char *group can be set to NULL on success groupname is returned on failure NULL is returned if bufsize is < 0 char *group can be set to nULL on success groupname is returned on failure an error message is printed and the program exits This changes were needed mainly for my new id applet. It is somewhat bigger then the previous but matches the behaviour of GNU id and is capable to handle usernames of whatever length. BTW: at a first look it seems to me that it will integrate well (with just a few changes) with the pending patch in patches/id_groups_alias.patch. The increase in size is balanced by the removal of my_getpwnamegid.c from libbb as this was used only in previous id applet and by size optimizations made possible in whoami.c and in passwd.c. I know that we are in feature freeze but I think that i've tested it enough (at least I hope so.......).

Tito writes:

2004-08-26T22:18:59+00:00

Hi, I've spent the half night staring at the devilish my_getpwuid and my_getgrgid functions trying to find out a way to avoid actual and future potential buffer overflow problems without breaking existing code. Finally I've found a not intrusive way to do this that surely doesn't break existing code and fixes a couple of problems too. The attached patch: 1) changes the behaviour of my_getpwuid and my_getgrgid to avoid potetntial buffer overflows 2) fixes all occurences of this function calls in tar.c , id.c , ls.c, whoami.c, logger.c, libbb.h. 3) The behaviour of tar, ls and logger is unchanged. 4) The behavior of ps with somewhat longer usernames messing up output is fixed. 5) The only bigger change was the increasing of size of the buffers in id.c to avoid false negatives (unknown user: xxxxxx) with usernames longer than 8 chars. The value i used ( 32 chars ) was taken from the tar header ( see gname and uname). Maybe this buffers can be reduced a bit ( to 16 or whatever ), this is up to you. 6) The increase of size of the binary is not so dramatic: size busybox text data bss dec hex filename 239568 2300 36816 278684 4409c busybox size busybox_fixed text data bss dec hex filename 239616 2300 36816 278732 440cc busybox 7) The behaviour of whoami changed: actually it prints out an username cut down to the size of the buffer. This could be fixed by increasing the size of the buffer as in id.c or avoid the use of my_getpwuid and use getpwuid directly instead. Maybe this colud be also remain unchanged...... Please apply if you think it is ok to do so. The diff applies on today's cvs tarball (2004-08-25). Thanks in advance, Ciao, Tito