rsync - Jul 2002 - strip setuid/setgid bits on backup (was Re: small security-related rsync extension)

On Fri, 19 Jul 2002, Dan Stromberg wrote:
> Many apologies.  If we update on the nfs server, as we've intended all
> along, we should have no .nfs* files.
Well, here's one thing that could make them, even if they're being
created
only directly, not over NFS.
I'm watching the directory you're syncing into.
I open the file  while it's still there.
You delete it, and I've got my .nfs* file.

Tim Conway
tim.conway@philips.com
303.682.4917 office, 3039210301 cell
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, n9hmg on AIM
perl -e 'print pack(nnnnnnnnnnnn, 
19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970), 
".\n" '
"There are some who call me.... Tim?"

On 19 Jul 2002, tim.conway@philips.com wrote:
> On Fri, 19 Jul 2002, Dan Stromberg wrote:
> 
> > Many apologies.  If we update on the nfs server, as we've intended
all
> > along, we should have no .nfs* files.
.nfs files are created on the server, but they are created *by* a command
from the client.  The client sends a RENAME op rather than UNLINK if the
dentry is still in use.
 
> Well, here's one thing that could make them, even if they're being
created
> only directly, not over NFS.
> I'm watching the directory you're syncing into.
> I open the file  while it's still there.
> You delete it, and I've got my .nfs* file.
(Why not just exploit the hole directly?)

Yes, but as I said the same problem exists with any tool run on the client:
cp, rpm, ...

It really is an interesting bug, but it's just not an rsync bug.  I might 
send mail (crediting Dan) to the Linux NFS client maintainer and see what
they say.

-- 
Martin