Fwd: Re: need help with an rsync patch

[Sherin A]

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
>>> directory-entry.
>> 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
> inode.
>
> 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.
> Ack.
>
>
>
  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. :(

-- 
--------------------------------------
Regards
Sherin A
http://www.sherin.co.in/