security bug in cp(1)

[Soren Spies]

I just noticed that cp -p doesn't update the group on a file before
writing data into the target.  That means that during the copy, users
you didn't intend to be able to read the file can read the file.

Running running Debian GNU/Linux 4.0 (etch) on i686.

techhouse-0:/scratch/soren=> ls -l spool.16Aug07
-rw-r----- 1 soren adm 43105807 2007-08-15 21:17 spool.16Aug07
techhouse-0:/scratch/soren=> cp -p spool.16Aug07 whenadm
[3] + Stopped              cp -p spool.16Aug07 whenadm
techhouse-0:/scratch/soren=> ls -l whenadm
-rw-r----- 1 soren ssl-cert 16728064 2007-08-16 21:41 whenadm
        [huh, why can ssl-cert users (26 of them) read my file?]
        [oddly my primary GID is ssl-cert; I think that used to be 'users' ;p]
techhouse-0:/scratch/soren=> fg
cp -p spool.16Aug07 whenadm
        `[now that it's finished]
techhouse-0:/scratch/soren=> ls -l whenadm
-rw-r----- 1 soren adm 43105807 2007-08-15 21:17 whenadm
[and finally it's right]


cp(1) says that <address@hidden> is the place for cp bugs.
Is there a way to search the bug database? gnu.org's fileutils page
(<http://www.gnu.org/software/fileutils/doc/manual/html/fileutils.html>)
has a link to bugs but it leads to a file-not-found page.  :P

I can't believe that no one has noticed this bug before and yet if they
had, surely it would have been fixed before.  Cc'ing <address@hidden>.


-Soren