On 16 Jul 2002, Dan Stromberg <[EMAIL PROTECTED]> wrote: > If by sillyrename, you mean busy text files are renamed to .nfs*,
"sillyrename" is in fact the technical term for this. I am not making it up. I'm pretty sure Callaghan's book calls it that, Sun people call it that, and it is the term used in the Linux NFSv3 implementation, etc. http://www.google.com/search?q=sillyrename > then I think you're missing how it works yourself, I'm sorry to say. > > You just unlink something on the server, and it happens, like magic. > Maybe that happens on the client side - but that's really beside the > point. Rename will probably do just as well. "it happens, like magic." Uh-huh. My understanding of sillyrename, from memory and a brief perusal of the kernel source (I don't have Callaghan here), is as follows: It is a purely client-side behaviour, to handle the fact that Unix files may be still open when unlinked. This relies on Unix having an in-memory use count, in addition to the on-disk link count. The problem is that the NFS server may reboot while the client has the file open, therefore losing its in-memory use count, and causing the file data to be garbage-collected by fsck. As a workaround, deletes or link-replacement on the client for a file still in use are handled by moving that file to a temporary name, so that from the point-of-view of other clients the file has gone. When the use count drops to zero, the client removes the .nfs file. If the client crashes or the net is partitioned before the use count goes to zero, then the .nfs file may remain indefinitely, which is why you need a reaper run from cron. If this is wrong please explain how. This is, incidentally, a much better solution for replacing in-use files than rsync's backups, because it only affects in-use files, and they are gc'd when no longer in use. Replacing local files and letting the kernel handle it is even better, because it can never leak. > .nfs* may well suffer from the same "the backup file is still setuid" > problem though. Yes; if you replace in-use setuid binaries in such a way that sillyrename orphans may be generated, then they may still be setuid, and that may be a security problem. I agree. These files should only be generated by edge cases where the program is in use when replaced, and where the client loses contact with the server or abruptly reboots. Presumably if you're installing a security update to a program then you need to restart that program fairly promptly, so the window should be small. Of course small window != zero, but there is no need to unnecessarily panic. It looks like the root problem is that replacing a setuid file from an NFS client may cause a setuid sillyrename file to remain under some circumstances. I haven't tested it, but I can believe that might happen. Is that what you're trying to say? If this is true, then it is a problem with NFS, not with rsync. The failure would presumably occur in the same way if you used dpkg, rpm, pkgadmin or cp to replace the files. > I'm finding it hard to see why this makes the issue moot. It is moot because you can just run rsync direct to the NFS server. This is faster and avoids the security hole. If you disagree, please explain why. > I'm also finding it hard to understand why security might be so > unimportant to you. I seriously wish you'd read bugtraq for a few > months before making such a short sighted decision. I have a pretty good understanding of Unix security, and I do consider it important. If you want changes to rsync you have to make a clear case, not just wave your hands and say "like magic". -- Martin -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html