On Tue, Aug 27, 2013 at 8:03 PM, Sherin A sherin...@gmail.com wrote:
Hope they will report it as a vulnerability , because this POC has been
exploited successfully and it is affected by all software that use rsync
as a backup and restore tool.
This is totally false. The vulnerability
On Thursday 29 August 2013 11:46 PM, Wayne Davison wrote:
On Tue, Aug 27, 2013 at 8:03 PM, Sherin A sherin...@gmail.com
mailto:sherin...@gmail.com wrote:
Hope they will report it as a vulnerability , because this POC
has been exploited successfully and it is affected by all
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chown itself is not insecure. The indiscriminate chowning of all
files creates security issues.
You can use --fake-super on push backups. In fact that is what
- --fake-super is DESIGNED FOR. You just have to make sure that
- --fake-super is
The solution is not to refuse to backup any file that is a hard link.
There are legitimate reasons to have hard links and ignoring them
means you aren't backing up everything.
I agree that preserving hard links may be important in some situation. There
are certainly legitimate reasons to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My opinion on backups is pretty simplistic. If a restore of my backup
doesn't bring me back to what I had when I backed up then I don't have
a backup.
If I have to restore something and the relationship between files that
were hard linked in the
On Wednesday 28 August 2013 04:14 AM, Kevin Korb wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My opinion on backups is pretty simplistic. If a restore of my backup
doesn't bring me back to what I had when I backed up then I don't have
a backup.
If I have to restore something and the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Only when you choose to force a completely unnecessary chown between
the backup and restore process.
On 08/27/13 23:03, Sherin A wrote:
On Wednesday 28 August 2013 04:14 AM, Kevin Korb wrote: My opinion
on backups is pretty simplistic. If a
On Wednesday 28 August 2013 08:36 AM, Kevin Korb wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Only when you choose to force a completely unnecessary chown between
the backup and restore process.
On 08/27/13 23:03, Sherin A wrote:
On Wednesday 28 August 2013 04:14 AM, Kevin Korb wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It can push or pull. The important part is that it runs as root on
one end and with --fake-super on the other end.
On 08/17/13 00:07, Sherin A wrote:
On Thursday 15 August 2013 01:25 AM, Kevin Korb wrote: It works if
you use --fake-super on the
On Thursday 15 August 2013 01:25 AM, Kevin Korb wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It works if you use --fake-super on the side that isn't super. That
is the only side that needs it:
asylum# id kmk
uid=12313(kmk) gid=100(users)
groups=100(users),10(wheel),16(cron),35(games)
On Tuesday 13 August 2013 10:24 PM, Justin T Pryzby wrote:
On Tue, Aug 13, 2013 at 10:10:04PM +0530, Sherin A wrote:
I am doing rsync from root@10.0.0.10/home/foo to
storageuser@10.0.0.20/home/storageuser/dailybackup/foo over ssh (no
role for -H)
Why not rsync from root to root? Or use
On Wednesday 14 August 2013 08:29 PM, Justin Pryzby wrote:
On Wed, Aug 14, 2013 at 04:09:46PM +0530, Sherin A wrote:
On Tuesday 13 August 2013 10:24 PM, Justin T Pryzby wrote:
PS : if any one interested in making a patch with an additional
option for rsync for excluding hardlinks with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As has been pointed out to you your problem is not hard links. Your
problem is the indiscriminate use of a root operation (a chown) during
the restoration process.
You should be solving this by either:
A) backing up and restoring the original owner
On Wednesday 14 August 2013 10:25 PM, Kevin Korb wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As has been pointed out to you your problem is not hard links. Your
problem is the indiscriminate use of a root operation (a chown) during
the restoration process.
You should be solving
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The point of --fake-super is that when you restore the file with
- --fake-super it will restore with the original ownership. Of course
that means that the restore has to be run with super privs on the
target and --fake-super on the source.
On
On Wednesday 14 August 2013 11:04 PM, Kevin Korb wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The point of --fake-super is that when you restore the file with
- --fake-super it will restore with the original ownership. Of course
that means that the restore has to be run with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It works if you use --fake-super on the side that isn't super. That
is the only side that needs it:
asylum# id kmk
uid=12313(kmk) gid=100(users)
groups=100(users),10(wheel),16(cron),35(games)
asylum# ls -l ~kmk/testfile
- -rw-r- 1 kmk users 0
Hello Kevin,
I tested this with rsync version 3.0.9 , but this is not working .
Even if we use fake-super or what ever option , these files will be
copied into the remote ssh account under that users ownership.
root@cptest [~]# ll -d /home/dom2inho
drwx--x--x 11 dom2inho dom2inho 4096
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
You are putting the --fake-super on the wrong side of the connection.
It must be on the side of the connection where rsync is not running
as root. That is why in my example I used
- --rsync-path='/usr/bin/rsync --fake-super'. That tells it to run
On Tuesday 13 August 2013 12:23 PM, Joe wrote:
Is there any way at all to say which is the original file and which is
the hard link? I'll bet there isn't, although I' m not an internals guy
at all. If so, this would be impossible to do. The inode is the
original, but all the file table
I'm going to give this one more shot and then wait for the experts to
weigh in.
I'll stick with your example of /etc/shadow, but this applies to any
secured file on the system.
On my system /etc/shadow is 640 (by default), so, as a normal user, I
can't even see it (other than to see that it
On Tue 13 Aug 2013, Sherin A wrote:
But if a user create a
hard link to /etc/shadow from his home dir , and he request a restore ,
then he can read the shadow files and decrypt it .
If he can make a HARD link to the shadow file, then he can already read
it - and worse.
Paul
--
Please use
Hello Joe,
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
On 13.08.2013 09:52, Paul Slootman wrote:
On Tue 13 Aug 2013, Sherin A wrote:
But if a user create a
hard link to /etc/shadow from his home dir , and he request a restore ,
then he can read the shadow files and decrypt it .
If he can make a HARD link to the shadow file, then he can
On Tue 13 Aug 2013, Matthias Schniedermeyer wrote:
On 13.08.2013 09:52, Paul Slootman wrote:
On Tue 13 Aug 2013, Sherin A wrote:
But if a user create a
hard link to /etc/shadow from his home dir , and he request a restore ,
then he can read the shadow files and decrypt it .
If
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
--
Please use reply-all for most replies to avoid omitting the mailing
On 13.08.2013 14:18, Paul Slootman wrote:
On Tue 13 Aug 2013, Matthias Schniedermeyer wrote:
Hardlinking a file doesn't change it's owner/group/permission
(All Hardlinks have the same user/group/permissions).
I never said that.
You implied that by your assertion that you
On 13.08.2013 14:20, 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.
I read your sentence
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
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
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
On Tuesday 13 August 2013 07:51 PM, Matthias Schniedermeyer wrote:
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
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
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
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.
On Tuesday 13 August 2013 09:07 PM, Justin T Pryzby wrote:
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
On Tue, Aug 13, 2013 at 09:43:06PM +0530, Sherin A wrote:
If linux user foo , with home /home/foo , what ownership we need
to give the files under his home folder , it must be foo and not
root.
Why? The user created the hardlink themselves, and it had root
ownership, why should the
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
On Tuesday 13 August 2013 09:49 PM, Justin T Pryzby wrote:
On Tue, Aug 13, 2013 at 09:43:06PM +0530, Sherin A wrote:
If linux user foo , with home /home/foo , what ownership we need
to give the files under his home folder , it must be foo and not
root.
Why? The user created the hardlink
On Tue, Aug 13, 2013 at 10:10:04PM +0530, Sherin A wrote:
I am doing rsync from root@10.0.0.10/home/foo to
storageuser@10.0.0.20/home/storageuser/dailybackup/foo over ssh (no
role for -H)
Why not rsync from root to root? Or use the rsync protocol (not over
ssh). Note that you can use -H
On Tue, Aug 13, 2013 at 9:40 AM, Sherin A sherin...@gmail.com wrote:
I am doing rsync from root@10.0.0.10/home/foo to
storageuser@10.0.0.20/home/**storageuser/dailybackup/foohttp://storageuser@10.0.0.20/home/storageuser/dailybackup/foo
over ssh (no role for -H) , so the storage files
Thanks Matt, that was great information.
I think I don't need to use exclude at all and just need to user H and P
flags with --filter option. Also I will need to use --delete option to
remove directories filtered H flag. The below command meets exactly my
requirements:
rsync -avz /foo/bar/
Matt McCutchen (m...@mattmccutchen.net) wrote on 26 July 2009 17:45:
On Sun, 2009-07-26 at 21:37 +0530, Jignesh Shah wrote:
I have a situation where I want to delete some of my excluded patterns
but still want to preserve some other. For example consider below
source and destination
Yup, it is working.
On Mon, Jul 27, 2009 at 7:42 PM, Carlos Carvalho car...@fisica.ufpr.brwrote:
Matt McCutchen (m...@mattmccutchen.net) wrote on 26 July 2009 17:45:
On Sun, 2009-07-26 at 21:37 +0530, Jignesh Shah wrote:
I have a situation where I want to delete some of my excluded
On Sun, 2009-07-26 at 21:37 +0530, Jignesh Shah wrote:
I have a situation where I want to delete some of my excluded patterns
but still want to preserve some other. For example consider below
source and destination directory hierarchy.
SourceDest
--
On 5/4/07, akahitz [EMAIL PROTECTED] wrote:
hi there,
i have a rsync server running in deamon mode, with a 1000 plus clients
connecting to it to retrieve files.
the problem is that when the clients connects the server has many rsync
processes running on it, each of which is around 3.8mb each.
On Thu, Jul 28, 2005 at 02:09:31AM +0200, [EMAIL PROTECTED] wrote:
But the rsync source isn't beautiful or structured - it's just a big
hunk of code.
Right -- it's a utility, not a library (though someone is working on
making it a library). I'd recommend looking into the librsync project
root access (root by any name is UID 0)
can read and write anything anywhere
You might add stuff like
list = false
read only = true
depending on what access you need
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
VC123
Sent: Tuesday,
Thnaks for yr reply.How can I restrict the client to not be able to
upload any file or write any file if rsyncd.conf contains uid=0 and
gid=0 ?
Thanks,
VC
--- [EMAIL PROTECTED] wrote:
root access (root by any name is UID 0)
can read and write anything anywhere
You might add stuff like
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Need Help with rsyncd.conf
Thnaks for yr reply.How can I restrict the client to not be able to
upload any file or write any file if rsyncd.conf contains uid=0 and
gid=0 ?
Thanks,
VC
--- [EMAIL PROTECTED] wrote:
root access (root by any name
On Mon 25 Apr 2005, VC123 wrote:
:
rsync /export/home/amg/* [EMAIL PROTECTED]:/export/home/amg
[EMAIL PROTECTED]'s password:
rsync: connection unexpectedly closed (0 bytes received so far)
[sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(359)
Try running with
Thanks Paul,
Tried with more options like --rsync-path= and it worked.
Regards,
VC
--- Paul Slootman [EMAIL PROTECTED] wrote:
On Mon 25 Apr 2005, VC123 wrote:
:
rsync /export/home/amg/* [EMAIL PROTECTED]:/export/home/amg
[EMAIL PROTECTED]'s password:
rsync: connection unexpectedly
Hi,
...
rsync -av --exclude=/foo/test/dir1/ /foo/test serv2:/foo
and the exclude still does not work.
The following works:
rsync -av --exclude=/test/dir1/ /foo/test serv2:/foo
Why?
Because one should think the exclude pathnames are *relative* ones to
the destination directory.
In your
On Tue, 25 Nov 2003, daniel [EMAIL PROTECTED] wrote:
Hi all,
I am having *massive* problems trying to exclude a single directory from an rsync.
I have serv1 and serv2. I am trying to rsync /foo/test from serv1 to
/foo on serv2 I want to exclude the directory /foo/test/dir1 So I try:
Hi all,
I am having *massive* problems trying to exclude a single directory from an rsync.
I have serv1 and serv2. I am trying to rsync /foo/test from serv1 to /foo on serv2
I want to exclude the directory /foo/test/dir1 So I try:
rsync -av --exclude-from=/foo/rsync.excludes
On Tue, Nov 25, 2003 at 03:53:10AM -0600, daniel wrote:
Thank you for clarifying the issue with regard to the fact that the
exclude pattern is relative to the destination path.
No, it's relative to the root of the transfer -- i.e. the names that the
two sides have in common.
The fact that:
On Tue, Nov 25, 2003 at 03:53:10AM -0600, daniel wrote:
Thank you for clarifying the issue with regard to the fact that the
exclude pattern is relative to the destination path.
No, it's relative to the root of the transfer -- i.e. the names that the
two sides have in common.
First
derix suartyo wrote:
Dear Expert,
I'm very newbie with rsync and i just installed RSYNC
in both of my servers. Let say the server is ServerA
(10.1.1.1) and ServerB (10.1.1.2). Rsync daemon runs
in server A. The rsycnd.conf is like this (i save this
file in /etc/rsyncd.conf):
uid
To use the rsync --daemon, you need to use two colons after the server name.
The next problem you'll probably run into is that you'll need
read only = no in rsyncd.conf.
- Dave Dykstra
On Tue, Mar 12, 2002 at 06:26:12PM +1000, Rsync mail Account wrote:
I have so far been unable to get rsync
PROTECTED]
Sent: Wednesday, March 13, 2002 3:53 PM
Subject: Re: Need help getting rsync working...
On 13 Mar 2002, Brad [EMAIL PROTECTED] wrote:
Thanks for the reply Dave. I have added your recommended, read only =
no
to rsyncd.conf and put 2 colons as you suggested, and now I get:
rsync
PROTECTED]
To: Brad [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; Dave Dykstra [EMAIL PROTECTED]
Sent: Wednesday, March 13, 2002 3:51 PM
Subject: Re: Need help getting rsync working...
hi Brad,
Since dave is probably sleeping right now and I am in avoidance mode
Brad [EMAIL PROTECTED] writes
On 13 Mar 2002, Brad [EMAIL PROTECTED] wrote:
Thanks for your reply Greg.
As you suggested, I have typed in:
rsync /tmp/sheepb.jpg RH72TB::testmodule/
and it just does a CR-LF with no errors, but the file is not on the server
hard drive. I wonder where it has gone? :-))
Now try
rsync
62 matches
Mail list logo
