While trying to implement the previously-discussed feature (adding a
prefix to all remotely-provided paths in server mode), I've come upon
what appears to be a bug in the server-mode security model.
Tue Aug 16 00:24:51 2005 Server sending (0): None
Tue Aug 16 00:24:51 2005 Client received (0)
> Charles Duffy <[EMAIL PROTECTED]>
> wrote the following on Tue, 16 Aug 2005 01:07:32 -0500
> While trying to implement the previously-discussed feature (adding a
> prefix to all remotely-provided paths in server mode), I've come upon
> what appears to be a bug in the server-mode securit
On Tue, 2005-08-16 at 23:24 -0500, Ben Escoto wrote:
> > Charles Duffy <[EMAIL PROTECTED]>
> > wrote the following on Tue, 16 Aug 2005 01:07:32 -0500
> > While trying to implement the previously-discussed feature (adding a
> > prefix to all remotely-provided paths in server mode), I've com
> Charles Duffy <[EMAIL PROTECTED]>
> wrote the following on Tue, 16 Aug 2005 23:58:22 -0500
>
> If they aren't in the list of allowable commands, why am I seeing the
> client sending such requests and the server processing them? I don't
> thoroughly understand at what times and under what
On Tue, 16 Aug 2005, Charles Duffy wrote:
> > http://arctic.org/~dean/rdiff-backup/unattended.html
>
> Not workable in my situation:
>
> - The instructions from the page in question require work to be done on
> a per-server basis. I need to support tens to hundreds (and possibly
> someday thousa
On Tue, 2005-08-16 at 23:30 -0700, dean gaudet wrote:
> that's my bad really -- you actually only need a single special backup
> key... and you can clone the /root/.ssh/authorized_keys2 file everywhere
> with that one key.
Yes, and I realize that -- but it doesn't address the [important] "hosts
On Wed, 2005-08-17 at 01:33 -0500, Ben Escoto wrote:
> > Charles Duffy <[EMAIL PROTECTED]>
> > wrote the following on Tue, 16 Aug 2005 23:58:22 -0500
> >
> > If they aren't in the list of allowable commands, why am I seeing the
> > client sending such requests and the server processing the
On Wed, 2005-08-17 at 08:03 +0100, Keith Edmunds wrote:
> Charles Duffy wrote:
> > Hmm. See, my concern is protecting inappropriate files on host from
> > being accessed. Perhaps I'll want to use a different security layer in
> > addition to application-based measures.
>
> Charles, I know that you
Charles Duffy wrote:
Hmm. See, my concern is protecting inappropriate files on host from
being accessed. Perhaps I'll want to use a different security layer in
addition to application-based measures.
Charles, I know that you are against each server having its own username
on the backup server,
> Charles Duffy <[EMAIL PROTECTED]>
> wrote the following on Wed, 17 Aug 2005 01:54:18 -0500
> On the server:
> rdiff-backup --server --restrict "$DATAPATH" --force-path-prefix "$DATAPATH"
...
Thanks for the report, I can see the bug too (I'm not sure the mkdir
got through, since it isn
Ben Escoto wrote:
Well I don't really understand your setup yet, but it seems any way
you do it, the client will have to authenticate itself to the server
somehow. The script can just check these credentials in the same way
your patched rdiff-backup would.
It's not a matter of credentials --
> Charles Duffy <[EMAIL PROTECTED]>
> wrote the following on Thu, 18 Aug 2005 06:39:44 -0500
>
> Yes, I have one (netcat on the client, tcpsvd on the server). That's
> fine, it works -- but it rules out the (SSH-based) multi-server
> authentication mechansims which have been thus far sugg
Ben Escoto wrote:
Well I was just suggesting using usernames.. Like instead of having
the server run
rdiff-backup --restrict --force-path-prefix --server
you could have it run
cd ; sudo -u Y rdiff-backup --restrict . --server
to avoid patching rdiff-backup and for an
13 matches
Mail list logo
