IMPORTANT NOTICE
During the next period of time, the Thecus Wiki will migrate to a new site - the NAS Website. The migration is part of an improvement initiative, which includes giving the site a new look and making it more user friendly.
During the migration information may exist both at the old and new site, however slowly pages should start to be located mainly at the new site. Please see the NAS Website for details.
N5200 BUG: BusyBox 1.1.0
From Thecus Wiki
Contents |
Facts
Name: N5200 BusyBox 1.1.0 Bug
Maintainer(s): Andreas Vogel (omega)
Target: N5200
Firmware versions: all firmwares <= 1.00.05
Short Description
The BusyBox executable (/bin/busybox) version 1.1.0 used in the above specified firmware release is buggy. The commands chown, chmod and chgrp follow symbolic links when called with the -R switch where they shouldn't do that. This bug might cause an infinite loop when changing a share from private to public depending on the actual contents of that share.
Long Description
The chmod -R command changes the file mode for a complete directory tree recursively. Whenever it finds a symbolic link it will ignore it completely, because setting the mode of an symbolic link itself is not supported by unix (and not needed anyway) and traversing a symbolic is not wanted in order to avoid infinite loops (see the chmod(1) man page).
In opposite to that, the chmod -R command of busybox is traversing symbolic links, and, if you're having the wrong symbolic link in your data, it will never stop.
You can reproduce the bug by issuing the following commands:
mkdir /tmp/xdir ln -s /proc/self/fd /tmp/xdir/xfile chmod -R 777 /tmp/xdir/xfile
Thats all. If you try it on the N5200, it will run into an infinite loop (you can stop it by pressing CTRL-C). If you run his on a "normal" Linux system, nothing goes wrong.
As I'm building Linux distributions, I have the complete files of a Linux root filesystem on my N5200. And these root filesystems contain the standard link /dev/fd -> /proc/self/fd and therefore causes the above chmod command to fail.
As I told you in another mail, I fiddling with the ACL and file permissions. So I changed a share from private to public and one of the actions doing this is changing the file permissions to 777 using the chmod -R 777 command above.
Just to make it clear: I'm doing this the official way using the web interface. And the result is, that this procedure will run forever - you need to stop it by killing he chmod process manually (using ssh) or rebooting the system. But even then, the work intended to be done is not finished, because there is no change to change all the files to 777.
The busybox currently used in 1.00.05 is 1.1.0 from 13.1.2006 and in the source of chmod I can see the bug (missing check for symbolic links). In the actual version 1.3.1 this bug has been already solved.
Workaround
None yet.