[BusyBox 0006144]: cp clobbers symlink with actual file (mismatch with coreutils)

bugs at busybox.net bugs at busybox.net
Fri Nov 14 01:35:40 UTC 2008


A NOTE has been added to this issue. 
====================================================================== 
http://busybox.net/bugs/view.php?id=6144 
====================================================================== 
Reported By:                pgbovine
Assigned To:                BusyBox
====================================================================== 
Project:                    BusyBox
Issue ID:                   6144
Category:                   Standards Compliance
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
====================================================================== 
Date Submitted:             11-11-2008 11:22 PST
Last Modified:              11-13-2008 17:35 PST
====================================================================== 
Summary:                    cp clobbers symlink with actual file (mismatch with
coreutils)
Description: 
If A is a symlink to file B, then calling 'busybox cp A A' will actually
copy the contents of B into A and make it into a regular file, whereas
coreutils cp will simply exit with an error.  I've reproduced this in the
latest svn head as of today.

Setup:

$ echo 'hello' > B
$ ln -s B A
$ ls -l A B
lrwxrwxrwx 1 pgbovine users 1 2008-11-11 11:31 A -> B
-rw-r--r-- 1 pgbovine users 6 2008-11-11 11:30 B


Coreutils behavior:

$ cp A A
cp: `A' and `A' are the same file
$ echo $?
1

($? is to get exit code, which is 1 here, signaling error)

$ ls -l A B
lrwxrwxrwx 1 pgbovine users 1 2008-11-11 11:32 A -> B
-rw-r--r-- 1 pgbovine users 6 2008-11-11 11:32 B

(no change in A or B)


Busybox behavior:

$ ./busybox cp A A
$ echo $?
0
pgbovine at hexapod ~/busybox
$ ls -l A B
-rw-r--r-- 1 pgbovine users 6 2008-11-11 11:33 A
-rw-r--r-- 1 pgbovine users 6 2008-11-11 11:33 B
$ stat A B
  File: `A'
  Size: 6               Blocks: 8          IO Block: 4096   regular file
Device: 802h/2050d      Inode: 1279976     Links: 1
Access: (0644/-rw-r--r--)  Uid: (  501/pgbovine)   Gid: (  100/   users)
Access: 2008-11-11 11:33:24.000000000 -0800
Modify: 2008-11-11 11:33:24.000000000 -0800
Change: 2008-11-11 11:33:24.000000000 -0800
  File: `B'
  Size: 6               Blocks: 8          IO Block: 4096   regular file
Device: 802h/2050d      Inode: 1279975     Links: 1
Access: (0644/-rw-r--r--)  Uid: (  501/pgbovine)   Gid: (  100/   users)
Access: 2008-11-11 11:33:24.000000000 -0800
Modify: 2008-11-11 11:33:16.000000000 -0800
Change: 2008-11-11 11:33:16.000000000 -0800

(exit code is 0, signifying success, and now A is a REGULAR FILE with the
same contents as B)
====================================================================== 

---------------------------------------------------------------------- 
 vda - 11-11-08 12:24  
---------------------------------------------------------------------- 
This is a known difference.

I think that writing data into symlink destination in this situation would
be a very dangerous behavior.

If root copies a file into /home/john/, user john can create a malicious
symlink (say, pointing to /etc/shadow) and trick root into clobbering any
file on the filesystem. 

---------------------------------------------------------------------- 
 pgbovine - 11-13-08 14:51  
---------------------------------------------------------------------- 
thanks.  so what should the correct behavior be here then?  to simply
reject the input like coreutils does? 

---------------------------------------------------------------------- 
 vda - 11-13-08 17:35  
---------------------------------------------------------------------- 
This is a rare case where I'd rather keep current behavior. I am very much
against the situation when I cannot do

cp file /home/john

without paranoidal fear that john might be setting up a trap for me
there.
Especially that if I do want to write into symlinks, I can:

cat file >/home/john/file

If you think it's a wrong and adhering to POSIX behavior is soooo much
more important, please explain why do you think so. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-11-08 11:22  pgbovine       New Issue                                    
11-11-08 11:22  pgbovine       Status                   new => assigned     
11-11-08 11:22  pgbovine       Assigned To               => BusyBox         
11-11-08 12:24  vda            Note Added: 0015414                          
11-13-08 14:51  pgbovine       Note Added: 0015814                          
11-13-08 17:35  vda            Note Added: 0015834                          
======================================================================




More information about the busybox-cvs mailing list