Fwd: Re: need help with an rsync patch
ms at citd.de
Tue Aug 13 10:30:03 MDT 2013
On 13.08.2013 21:04, Sherin A wrote:
> On Tuesday 13 August 2013 08:56 PM, Matthias Schniedermeyer wrote:
> >On 13.08.2013 20:44, 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
> >The other solution, if possible, is using separate
> >As hardlinks only work inside a single filesystem, if you can
> >separate different things you significantly reduce the problematic
> >The described "problem" with /etc/shadow can be prevented by that, if
> >the file isn't on the same filesytem, it can't be hardlinked.
> >The advantage of this solution is that it workes for (all) older
> === Bum again the third post =======
> Thanks for your reply . But think about the real world users. There
> is not always necessary the /home will be in separate disk
> partition or /tmp , /var/tmp , /usr/tmp. Think about an openvz
> vps or disk with everything on / (most of the cloud servers) .
> Rsync is using in a lot of production servers as a better tool for
> file backups. As in the case of a hosting server , we can't always
> trust all hosting users in a single server. Also just ignore the
> shadow and let us say there are two user on /home/foo and
> /home/fun and the user fun created a hardlink to
> /hom/foo/joomla/configuration.php , which contains database
> information of user foo's joomla site . May be this user created
> this type hardlinks with all the directories and files inside
> /home . So simply requesting a restore will revert the files into
> his readable form and he can wipe out every thing
Restoring files with different user/group/permissions sounds like a
A part in my day-job is doing more or less exactly this. (Backup of
remote servers by rsync over ssh)
I rsync with "--numeric-ids" (in both directions) because that way i can
be sure that the files are (re)store with exactly the right uids/gids.
And not using "--inplace" makes sure that rsync breaks existing
hard-links, so it doesn't overwrite existing files. So a described
hardlink owned by root would still be restored, but without another step
by myself it still wouldn't be readable by the user that created the
But on most systems we administer/backup noone besides us as access to
the system, so i'm fortunate that there isn't much malicious activity.
<Knocking on wood>.
The more risky operation, in my case, is moving a web-site from one
server to another, in that case the owner/gid mostly need to be changed.
In the past i often did "chown -R newowner.newgroup *", which would have
made the file accessible.
But nowadays i usually do:
find . -uid <x> -print0 | xargs -0 chown -h <y>
find . -gid <x> -print0 | xargs -0 chgrp -h <y>
("chown -h" is so that symlinks are changed too)
Rsync 3.1 will have idmapping, i'm planning on using that in the future.
More information about the rsync