-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
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
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
31 matches
Mail list logo
