Fwd: Re: need help with an rsync patch
ms at citd.de
Tue Aug 13 08:21:35 MDT 2013
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
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.
More information about the rsync