Fwd: Re: need help with an rsync patch
sherinmon at gmail.com
Tue Aug 13 09:22:49 MDT 2013
On Tuesday 13 August 2013 07:51 PM, Matthias Schniedermeyer wrote:
> On 13.08.2013 15:51, Paul Slootman wrote:
>> On Tue 13 Aug 2013, Matthias Schniedermeyer wrote:
>>> I read your sentence differently:
>>>> If he can make a HARD link to the shadow file, then he can already
>>>> read it - and worse.
>>> My understanding of your sentence says:
>>> The ability to hardlink, means that anyone can read any file they can
>>> make a hardlink to.
>> Then I didn't express myself clearly enough. Again, keep in mind I was
>> thinking from the perspective of a linux 3.6 and up kernel without any
>> sys tweaks.
> 3.6 is NO different.
> For "least surprise" reasons with protected_hardlinks you can't create
> hardlinks to file you can't access. Nothing more.
> But that doesn't preclude:
> - Existing hardlinks
> - Someone with permission (e.g. root) to make a hardlink for you.
>>> Having access to the directory entry is not the same as having access to
>>> the inode. User/group/permission is on the inode NOT the
>> I have access to the inode when I do an "ls -l" of the file :-P
> No, you access to the directory entry, which contains a pointer to the
> But i wasn't describing what i meant clearly. What i actually meant is:
> Accesses to the "bytestream" pointed to by the inode (which in
> turn is pointed to by the directory entry)
> Directory entry -> inode -> bytestream
>> perhaps you mean "modification permissions".
> I think you mean "inode change modification". IOW permission to change
> the permission settings of a inode.
> 'man 2 chmod' says for who can change the permissions
> (manpages Version 3.52):
> - snip -
> The effective UID of the calling process must match the owner of
> the file, or the process must be privileged ... .
> - snip -
>> Then again, when hardlinking, I'm changing the link count which is
>> stored in the inode... :)
> True, but it's not something you do directly, it's a side-effect of the
> operation you told the kernel to execute. IOW the link-count is an
> implicitly handled implementation detail.
>> I'm done here... coming back to the OP's problem: if the backup is made
>> by root, then a user should not be allowed to access all parts of that
>> backup. The security problem is there, and not in rsync.
The problem occur after restore . If we restore files from the
backup location and set the ownership to his local files, then he can
read it. But there is no way to identify that hardlink after restore ,
because during the restore process , it will be a regular file instead
of the original hard link .
So the solution is , if a user have a million files , then we need to
read every and each files to see which have the server's confidential
data. So if there was an option to exclude hardlink before rsync ,
this won't happen.
Thank for all of you , let me know if we can figure this out. "Restore
the hardlink back to the original link instead of regular file" . It
is not possible , because hardlinks are not allowed across file systems. :(
More information about the rsync