0001477: cp does not work with /dev files - BusyBox Bug and Patch Tracking

Notes
(0002702) vda 08-29-07 03:48 edited on: 08-29-07 04:07	You are doing "cp file /dev/disk". You expect cp to open and overwrite /dev/disk. However, think what will happen if I do this: cp -a /backups/etc /tmp and malicious user created /tmp/etc/passwd symlink which points into his file? In order to prevent this, I should check beforehand whether /tmp/etc exists, and this stil isn't fail-safe - user can create /tmp/etc after I did the check, but before I do cp. Another example: user asked me to restore his homedir from backup. A friendly admin does this: cp -a /backups/home/user /home But user is malicious and he has created /home/user/new_passwd symlink which points to /etc/passwd, and backup also has user/new_passwd (as ordinary file). I consider this unacceptable. Yes, I can be paranoid, remember all these small nasty things and never copy stuff into /tmp, and do a zillion of checks when I copy stuff to user's dirs. But I rather don't. I want cp to NOT overwrite existing files, I want it to unlink and re-create them. I know that it isn't POSIX compliant. I think sanity sometimes is more important than POSIX. Back to your needs. Why can't you use "cat file >/dev/disk"?

(0002739) jackson 09-13-07 00:45	Can anyone give me the exact steps to reproduce this scenario.

(0002740) vda 09-13-07 08:17	Fixed in svn, will be in 1.7.1 http://busybox.net/downloads/fixes-1.7.0/busybox-1.7.0-cp.patch [^]

Relationships