Fwd: Re: need help with an rsync patch

[Matthias Schniedermeyer]

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.
> >>>
> >>>
> >>>Paul
> >>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
> >root/data(/whatever)-fileystems.
> >
> >As hardlinks only work inside a single filesystem, if you can
> >separate different things you significantly reduce the problematic
> >cases.
> >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
> >kernels.
> >
> >
> >
> === 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 
desaster.

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 
hardlink.

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.




-- 

Matthias