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