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 at 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 at 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
>