Fwd: Re: need help with an rsync patch

[Justin T Pryzby]

On Tue, Aug 13, 2013 at 08:44:08PM +0530, Sherin A wrote:
> On Tuesday 13 August 2013 05:50 PM, Paul Slootman wrote:
> >On Tue 13 Aug 2013, Matthias Schniedermeyer wrote:
> >>BUT there is no direct vulnerability in that, only processes after that
> >>(like backup/rsync) can make a vulnerability out of it.
> >... which is what I already wrote.
> So the solutions is to upgrade the kernel to 3.6  in all Operating
> systems installations. ?  If it is one server  , then it  was a
> solution.  Is it possible to add a flag to exclude hard inks of
> regular file instead of waiting the OS vendors for updating there
> kernel  to 3.6

Matthias already pointed out that the changed default behavior in
new kernel is meant to help users avoid shooting themselves in the
foot, but doesn't implement added security.  In particular, it doesn't
fix pre-existing hardlinks created by users who can't read the file;
indeed, it can't, since there is no place where the "creator" of the
hardlink is stored.

You need to realize that every normal file is a hardlink.  /etc/shadow
is a hardlink, as is $HOME/my_shadow.  There is no "original" or "more
important" link to the file, they are all equal in the eyes of the
kernel.

Why are your files being restored with different access permissions
than the original file?  The UID/GID/mode should be restored to the
same values as in the backup.  A users hardlink of /etc/shadow will be
restored as root/root, 00640, same as the hardlink before backup, and
(necessarily) the same as the original file (remember, every link
points to an inode, which is where the metadata is stored:
UID/GID/perms/timestamps).

Justin