I'm going to give this one more shot and then wait for the experts to weigh in.
I'll stick with your example of /etc/shadow, but this applies to any secured file on the system. On my system /etc/shadow is 640 (by default), so, as a normal user, I can't even see it (other than to see that it exists) to do anything with it. Probably any user who can see it to link to it could copy it too. Once copied, it could be decrypted at leisure. The point is to secure it to begin with, then any normal backup should not be an issue. Since my /home is on its own partition, I can't even attempt a hard link: bigbird@ramdass:~/sandbox$ ln /etc/shadow . ln: failed to create hard link `./shadow' => `/etc/shadow': Invalid cross-device link My /tmp is in the same partition as /etc, but bigbird@ramdass:~/sandbox$ ln /etc/shadow /tmp ln: failed to create hard link `/tmp/shadow' => `/etc/shadow': Operation not permitted As a regular user, my home directory is pretty much the only place I have write access to (aside from /tmp which works the same way for most practical purposes.) My simplistic understanding of the Linux file system is that each file consists of device storage which is mapped in a single inode (unless there is some fancy stuff to handle extremely large files). The inode number is then recorded in a file table entry somewhere - and that's essentially what a hard link is. If there are more than one hard links to the file (additional file table entries with the same inode number in them), then a counter in the inode (*not* in the file table entry, etc.) is incremented for each additional one. Each of these "files" or hard links is just a file table entry that points to the inode. No one of them is distinguished as the "original" one as opposed to one created subsequently. There's no useful way to tell them apart other than their differing positions in the file table/directory structure and the fact that they can have different names. The counter is in the inode so that it can be decremented as file table entries are deleted. If it gets to zero, then there is no file table entry pointing to that inode and the system can then release the device storage that was mapped/reserved in the inode so that it can be reused. This is one of the things fsck checks for when repairing damaged file tables. In short, 1) There is really no such thing as a file with more than one link to it. It's the inode and there's only one for each allocated set of device storage. 2) If a file is secure to start with, nobody without elevated security permissions should be able to access it insecurely, including linking to it or copying it. If someone you don't trust completely has access to elevated permissions on your system, then backup is the least of your problems. Joe On 08/13/2013 03:00 AM, Sherin A wrote: > On Tuesday 13 August 2013 12:23 PM, Joe wrote: >> Is there any way at all to say which is the original file and which is >> the hard link? I'll bet there isn't, although I' m not an internals guy >> at all. If so, this would be impossible to do. The inode is the >> "original", but all the file table entries to it are hard links (if >> they're not symlinks.) >> >> I guess the question is, what do you really want to accomplish? >> >> The fact that more than one hard link exists probably means it really >> does need to be backed up - or that the hard link shouldn't be there in >> the original file system. >> >> Joe >> >> On 08/13/2013 01:11 AM, Sherin A wrote: >>> Can some one create a patch for excluding "hard link regular file" >>> from copying ?. May be like a command flag , rsync >>> --no-hardlink-copy .... >>> > Hello Jose, > > I think it is possible to check whether a file is regular file > or having more than one links, ( you can check it with stat system > call ) > > The situation is we have an rsync command in a server which will copy > files of local users into a remote server / filesystem . Also have > ability to restore it , it is simple backup. But if a user create a > hard link to /etc/shadow from his home dir , and he request a restore > , then he can read the shadow files and decrypt it . > > So if there is an option to avoid hardlinks during copy process , > it is will add and extra security , it only need to add the following > check condition , > > 1) Check the file that are going to copy is a regular file or having > more than 1 links > > Also we have checked a lot of other thridparty software that use this > rsync too, which all have this race condition exploit running on . > > let me know if you need a POC > -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
