Fwd: Re: need help with an rsync patch

Matthias Schniedermeyer 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 mailing list