public inbox for [email protected]
help / color / mirror / Atom feedAvoid leaking system path from pg_available_extensions
9+ messages / 4 participants
[nested] [flat]
* Avoid leaking system path from pg_available_extensions
@ 2026-05-20 01:00 Chao Li <[email protected]>
0 siblings, 2 replies; 9+ messages in thread
From: Chao Li @ 2026-05-20 01:00 UTC (permalink / raw)
To: pgsql-hackers; +Cc: Andrew Dunstan <[email protected]>; Matheus Alcantara <[email protected]>
Hi,
I just tested “Add paths of extensions to pg_available_extensions”, and found an issue.
This is a simple repro:
```
evantest=# reset extension_control_path;
RESET
evantest=# select * from pg_available_extensions where name = 'plpgsql';
name | default_version | installed_version | location | comment
---------+-----------------+-------------------+----------+------------------------------
plpgsql | 1.0 | 1.0 | $system | PL/pgSQL procedural language
(1 row)
evantest=# set extension_control_path='';
SET
evantest=# select * from pg_available_extensions where name = 'plpgsql';
name | default_version | installed_version | location | comment
---------+-----------------+-------------------+----------------------------------+------------------------------
plpgsql | 1.0 | 1.0 | /usr/local/pgsql/share/extension | PL/pgSQL procedural language
(1 row)
```
When extension_control_path is not set, location shows “$system", which is consistent with what the documentation says:
```
<para>
The default value for this parameter is
<literal>'$system'</literal>. If the value is set to an empty
string, the default <literal>'$system'</literal> is also assumed.
</para>
```
However, as shown above, when I set extension_control_path to an empty string, the absolute system path is displayed. I consider this an information leakage bug.
The fix is straightforward; see the attached patch for details. After the fix, when extension_control_path is an empty string, location shows “$system” now:
```
evantest=# set extension_control_path='';
SET
evantest=# select * from pg_available_extensions where name = 'plpgsql';
name | default_version | installed_version | location | comment
---------+-----------------+-------------------+----------+------------------------------
plpgsql | 1.0 | 1.0 | $system | PL/pgSQL procedural language
(1 row)
```
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Avoid leaking system path from pg_available_extensions
@ 2026-05-20 01:07 Chao Li <[email protected]>
parent: Chao Li <[email protected]>
1 sibling, 1 reply; 9+ messages in thread
From: Chao Li @ 2026-05-20 01:07 UTC (permalink / raw)
To: pgsql-hackers; +Cc: Andrew Dunstan <[email protected]>; Matheus Alcantara <[email protected]>
> On May 20, 2026, at 09:00, Chao Li <[email protected]> wrote:
>
> Hi,
>
> I just tested “Add paths of extensions to pg_available_extensions”, and found an issue.
>
> This is a simple repro:
> ```
> evantest=# reset extension_control_path;
> RESET
> evantest=# select * from pg_available_extensions where name = 'plpgsql';
> name | default_version | installed_version | location | comment
> ---------+-----------------+-------------------+----------+------------------------------
> plpgsql | 1.0 | 1.0 | $system | PL/pgSQL procedural language
> (1 row)
>
> evantest=# set extension_control_path='';
> SET
> evantest=# select * from pg_available_extensions where name = 'plpgsql';
> name | default_version | installed_version | location | comment
> ---------+-----------------+-------------------+----------------------------------+------------------------------
> plpgsql | 1.0 | 1.0 | /usr/local/pgsql/share/extension | PL/pgSQL procedural language
> (1 row)
> ```
>
> When extension_control_path is not set, location shows “$system", which is consistent with what the documentation says:
> ```
> <para>
> The default value for this parameter is
> <literal>'$system'</literal>. If the value is set to an empty
> string, the default <literal>'$system'</literal> is also assumed.
> </para>
> ```
>
> However, as shown above, when I set extension_control_path to an empty string, the absolute system path is displayed. I consider this an information leakage bug.
>
> The fix is straightforward; see the attached patch for details. After the fix, when extension_control_path is an empty string, location shows “$system” now:
> ```
> evantest=# set extension_control_path='';
> SET
> evantest=# select * from pg_available_extensions where name = 'plpgsql';
> name | default_version | installed_version | location | comment
> ---------+-----------------+-------------------+----------+------------------------------
> plpgsql | 1.0 | 1.0 | $system | PL/pgSQL procedural language
> (1 row)
> ```
>
> Best regards,
> --
> Chao Li (Evan)
> HighGo Software Co., Ltd.
> https://www.highgo.com/
>
>
>
>
Oops, forgot the attachment. Here comes it.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
Attachments:
[application/octet-stream] v1-0001-Avoid-leaking-system-path-from-pg_available_exten.patch (2.6K, 2-v1-0001-Avoid-leaking-system-path-from-pg_available_exten.patch)
download | inline diff:
From 0f9398b34a5484edbb93cb7771d6204bb37b6f7c Mon Sep 17 00:00:00 2001
From: "Chao Li (Evan)" <[email protected]>
Date: Wed, 20 May 2026 08:49:15 +0800
Subject: [PATCH v1] Avoid leaking system path from pg_available_extensions
The documentation says that when extension_control_path is set to an
empty string, the default '$system' path is still assumed. However,
get_extension_control_directories() added the system extension directory
with a NULL macro in that case. As a result, pg_available_extensions
could expose the expanded system directory path instead of reporting
'$system' as the location.
Record the implicitly-added system directory with the '$system' macro, so
pg_available_extensions reports the documented symbolic location and does
not leak the actual system path.
Update the extension_control_path TAP test to check the reported location
directly.
Author: Chao Li <[email protected]>
Reviewed-by:
Discussion: https://postgr.es/m/
---
src/backend/commands/extension.c | 2 +-
.../modules/test_extensions/t/001_extension_control_path.pl | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/backend/commands/extension.c b/src/backend/commands/extension.c
index a330b5fd6ce..98f9d7018ae 100644
--- a/src/backend/commands/extension.c
+++ b/src/backend/commands/extension.c
@@ -526,7 +526,7 @@ get_extension_control_directories(void)
{
ExtensionLocation *location = palloc_object(ExtensionLocation);
- location->macro = NULL;
+ location->macro = pstrdup("$system");
location->loc = system_dir;
paths = lappend(paths, location);
}
diff --git a/src/test/modules/test_extensions/t/001_extension_control_path.pl b/src/test/modules/test_extensions/t/001_extension_control_path.pl
index c1cec0dc622..4a013a7da4b 100644
--- a/src/test/modules/test_extensions/t/001_extension_control_path.pl
+++ b/src/test/modules/test_extensions/t/001_extension_control_path.pl
@@ -109,10 +109,10 @@ is($ret, "t",
"\$system extension is shown correctly in pg_available_extensions");
$ret = $node->safe_psql('postgres',
- "set extension_control_path = ''; select count(*) > 0 as ok from pg_available_extensions where name = 'plpgsql'"
+ "set extension_control_path = ''; select location from pg_available_extensions where name = 'plpgsql'"
);
-is($ret, "t",
- "\$system extension is shown correctly in pg_available_extensions with empty extension_control_path"
+is($ret, "\$system",
+ "\$system location is shown correctly in pg_available_extensions with empty extension_control_path"
);
# Test with an extension that does not exists
--
2.50.1 (Apple Git-155)
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Avoid leaking system path from pg_available_extensions
@ 2026-05-21 08:55 lu feng <[email protected]>
parent: Chao Li <[email protected]>
0 siblings, 0 replies; 9+ messages in thread
From: lu feng @ 2026-05-21 08:55 UTC (permalink / raw)
To: Chao Li <[email protected]>; +Cc: pgsql-hackers; Andrew Dunstan <[email protected]>; Matheus Alcantara <[email protected]>
Chao Li <[email protected]> 于2026年5月20日周三 09:08写道：
>
>
> > On May 20, 2026, at 09:00, Chao Li <[email protected]> wrote:
> >
> > Hi,
> >
> > I just tested “Add paths of extensions to pg_available_extensions”, and
> found an issue.
> >
> > This is a simple repro:
> > ```
> > evantest=# reset extension_control_path;
> > RESET
> > evantest=# select * from pg_available_extensions where name = 'plpgsql';
> > name | default_version | installed_version | location |
> comment
> >
> ---------+-----------------+-------------------+----------+------------------------------
> > plpgsql | 1.0 | 1.0 | $system | PL/pgSQL
> procedural language
> > (1 row)
> >
> > evantest=# set extension_control_path='';
> > SET
> > evantest=# select * from pg_available_extensions where name = 'plpgsql';
> > name | default_version | installed_version | location
> | comment
> >
> ---------+-----------------+-------------------+----------------------------------+------------------------------
> > plpgsql | 1.0 | 1.0 |
> /usr/local/pgsql/share/extension | PL/pgSQL procedural language
> > (1 row)
> > ```
> >
> > When extension_control_path is not set, location shows “$system", which
> is consistent with what the documentation says:
> > ```
> > <para>
> > The default value for this parameter is
> > <literal>'$system'</literal>. If the value is set to an empty
> > string, the default <literal>'$system'</literal> is also assumed.
> > </para>
> > ```
> >
> > However, as shown above, when I set extension_control_path to an empty
> string, the absolute system path is displayed. I consider this an
> information leakage bug.
> >
> > The fix is straightforward; see the attached patch for details. After
> the fix, when extension_control_path is an empty string, location shows
> “$system” now:
> > ```
> > evantest=# set extension_control_path='';
> > SET
> > evantest=# select * from pg_available_extensions where name = 'plpgsql';
> > name | default_version | installed_version | location |
> comment
> >
> ---------+-----------------+-------------------+----------+------------------------------
> > plpgsql | 1.0 | 1.0 | $system | PL/pgSQL
> procedural language
> > (1 row)
> > ```
> >
> > Best regards,
> > --
> > Chao Li (Evan)
> > HighGo Software Co., Ltd.
> > https://www.highgo.com/
> >
> >
> >
> >
>
> Oops, forgot the attachment. Here comes it.
>
> Best regards,
> --
> Chao Li (Evan)
> HighGo Software Co., Ltd.
> https://www.highgo.com/
>
>
>
>
> Thanks for the patch. I just reproduced the problem and verified the fix.
So this patch looks good to me.
Regards,
Lu Feng
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Avoid leaking system path from pg_available_extensions
@ 2026-05-21 15:12 Matheus Alcantara <[email protected]>
parent: Chao Li <[email protected]>
1 sibling, 1 reply; 9+ messages in thread
From: Matheus Alcantara @ 2026-05-21 15:12 UTC (permalink / raw)
To: Chao Li <[email protected]>; pgsql-hackers; +Cc: Andrew Dunstan <[email protected]>
On 19/05/26 22:00, Chao Li wrote:
> I just tested “Add paths of extensions to pg_available_extensions”, and found an issue.
>
> This is a simple repro:
> ```
> evantest=# reset extension_control_path;
> RESET
> evantest=# select * from pg_available_extensions where name = 'plpgsql';
> name | default_version | installed_version | location | comment
> ---------+-----------------+-------------------+----------+------------------------------
> plpgsql | 1.0 | 1.0 | $system | PL/pgSQL procedural language
> (1 row)
>
> evantest=# set extension_control_path='';
> SET
> evantest=# select * from pg_available_extensions where name = 'plpgsql';
> name | default_version | installed_version | location | comment
> ---------+-----------------+-------------------+----------------------------------+------------------------------
> plpgsql | 1.0 | 1.0 | /usr/local/pgsql/share/extension | PL/pgSQL procedural language
> (1 row)
> ```
>
> When extension_control_path is not set, location shows “$system", which is consistent with what the documentation says:
> ```
> <para>
> The default value for this parameter is
> <literal>'$system'</literal>. If the value is set to an empty
> string, the default <literal>'$system'</literal> is also assumed.
> </para>
> ```
>
> However, as shown above, when I set extension_control_path to an empty string, the absolute system path is displayed. I consider this an information leakage bug.
>
> The fix is straightforward; see the attached patch for details. After the fix, when extension_control_path is an empty string, location shows “$system” now:
> ```
> evantest=# set extension_control_path='';
> SET
> evantest=# select * from pg_available_extensions where name = 'plpgsql';
> name | default_version | installed_version | location | comment
> ---------+-----------------+-------------------+----------+------------------------------
> plpgsql | 1.0 | 1.0 | $system | PL/pgSQL procedural language
> (1 row)
> ```
>
Hi, thank you for sharing the bug with the fix.
I've reproduced the issue and the fix looks correct to me.
--
Matheus Alcantara
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Avoid leaking system path from pg_available_extensions
@ 2026-05-22 07:25 Jim Jones <[email protected]>
parent: Matheus Alcantara <[email protected]>
0 siblings, 1 reply; 9+ messages in thread
From: Jim Jones @ 2026-05-22 07:25 UTC (permalink / raw)
To: Matheus Alcantara <[email protected]>; Chao Li <[email protected]>; pgsql-hackers; +Cc: Andrew Dunstan <[email protected]>
On 21/05/2026 17:12, Matheus Alcantara wrote:
> I've reproduced the issue and the fix looks correct to me.
same here, +1
I was wondering if creating a constant for it would be, stylistically
speaking, a cleaner solution. For instance:
#define EXTENSION_SYSTEM_MACRO "$system"
I realize that it's used only inside get_extension_control_directories()
but since it is even mentioned in the docs, I guess it wouldn't be a bad
idea.
Thanks!
Best, Jim
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Avoid leaking system path from pg_available_extensions
@ 2026-05-22 15:40 Matheus Alcantara <[email protected]>
parent: Jim Jones <[email protected]>
0 siblings, 1 reply; 9+ messages in thread
From: Matheus Alcantara @ 2026-05-22 15:40 UTC (permalink / raw)
To: Jim Jones <[email protected]>; Chao Li <[email protected]>; pgsql-hackers; +Cc: Andrew Dunstan <[email protected]>
On 22/05/26 04:25, Jim Jones wrote:
> On 21/05/2026 17:12, Matheus Alcantara wrote:
>> I've reproduced the issue and the fix looks correct to me.
>
> same here, +1
>
Thank you for also testing.
> I was wondering if creating a constant for it would be, stylistically
> speaking, a cleaner solution. For instance:
>
> #define EXTENSION_SYSTEM_MACRO "$system"
>
> I realize that it's used only inside get_extension_control_directories()
> but since it is even mentioned in the docs, I guess it wouldn't be a bad
> idea.
>
I'm not against it but I don't think that it's necessary since as you
mention, only get_extension_control_directories() use.
--
Matheus Alcantara
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Avoid leaking system path from pg_available_extensions
@ 2026-05-26 07:14 Chao Li <[email protected]>
parent: Matheus Alcantara <[email protected]>
0 siblings, 2 replies; 9+ messages in thread
From: Chao Li @ 2026-05-26 07:14 UTC (permalink / raw)
To: Matheus Alcantara <[email protected]>; +Cc: Jim Jones <[email protected]>; pgsql-hackers; Andrew Dunstan <[email protected]>
> On May 22, 2026, at 23:40, Matheus Alcantara <[email protected]> wrote:
>
> On 22/05/26 04:25, Jim Jones wrote:
>> On 21/05/2026 17:12, Matheus Alcantara wrote:
>>> I've reproduced the issue and the fix looks correct to me.
>> same here, +1
>
> Thank you for also testing.
>
>> I was wondering if creating a constant for it would be, stylistically
>> speaking, a cleaner solution. For instance:
>> #define EXTENSION_SYSTEM_MACRO "$system"
>> I realize that it's used only inside get_extension_control_directories()
>> but since it is even mentioned in the docs, I guess it wouldn't be a bad
>> idea.
>
> I'm not against it but I don't think that it's necessary since as you mention, only get_extension_control_directories() use.
>
> --
> Matheus Alcantara
> EDB: https://www.enterprisedb.com
In theory, I’m not against the idea either. In practice, there are many hard-coded strings in the source tree, and I’m not sure where the right place would be to define this macro.
Since this string is only used in get_extension_control_directories(), and now it is used three times, I defined it at the beginning of the function and undefined it at the end. Let’s see if there are any objections to that.
Please see the attached v2.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
Attachments:
[application/octet-stream] v2-0001-Avoid-leaking-system-path-from-pg_available_exten.patch (3.6K, 2-v2-0001-Avoid-leaking-system-path-from-pg_available_exten.patch)
download | inline diff:
From eaf271a14944df7df87601827f5f5e4909e38c33 Mon Sep 17 00:00:00 2001
From: "Chao Li (Evan)" <[email protected]>
Date: Wed, 20 May 2026 08:49:15 +0800
Subject: [PATCH v2] Avoid leaking system path from pg_available_extensions
The documentation says that when extension_control_path is set to an
empty string, the default '$system' path is still assumed. However,
get_extension_control_directories() added the system extension directory
with a NULL macro in that case. As a result, pg_available_extensions
could expose the expanded system directory path instead of reporting
'$system' as the location.
Record the implicitly-added system directory with the '$system' macro, so
pg_available_extensions reports the documented symbolic location and does
not leak the actual system path.
Update the extension_control_path TAP test to check the reported location
directly.
Author: Chao Li <[email protected]>
Reviewed-by: Lu Feng <[email protected]>
Reviewed-by: Matheus Alcantara <[email protected]>
Reviewed-by: Jim Jones <[email protected]>
Discussion: https://postgr.es/m/[email protected]
---
src/backend/commands/extension.c | 8 +++++---
.../test_extensions/t/001_extension_control_path.pl | 6 +++---
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/src/backend/commands/extension.c b/src/backend/commands/extension.c
index a330b5fd6ce..d073585c421 100644
--- a/src/backend/commands/extension.c
+++ b/src/backend/commands/extension.c
@@ -513,6 +513,7 @@ is_extension_script_filename(const char *filename)
static List *
get_extension_control_directories(void)
{
+#define EXTENSION_SYSTEM_MACRO "$system"
char sharepath[MAXPGPATH];
char *system_dir;
char *ecp;
@@ -526,7 +527,7 @@ get_extension_control_directories(void)
{
ExtensionLocation *location = palloc_object(ExtensionLocation);
- location->macro = NULL;
+ location->macro = pstrdup(EXTENSION_SYSTEM_MACRO);
location->loc = system_dir;
paths = lappend(paths, location);
}
@@ -556,10 +557,10 @@ get_extension_control_directories(void)
* Substitute the path macro if needed or append "extension"
* suffix if it is a custom extension control path.
*/
- if (strcmp(piece, "$system") == 0)
+ if (strcmp(piece, EXTENSION_SYSTEM_MACRO) == 0)
{
location->macro = pstrdup(piece);
- mangled = substitute_path_macro(piece, "$system", system_dir);
+ mangled = substitute_path_macro(piece, EXTENSION_SYSTEM_MACRO, system_dir);
}
else
{
@@ -582,6 +583,7 @@ get_extension_control_directories(void)
}
return paths;
+#undef EXTENSION_SYSTEM_MACRO
}
/*
diff --git a/src/test/modules/test_extensions/t/001_extension_control_path.pl b/src/test/modules/test_extensions/t/001_extension_control_path.pl
index c1cec0dc622..4a013a7da4b 100644
--- a/src/test/modules/test_extensions/t/001_extension_control_path.pl
+++ b/src/test/modules/test_extensions/t/001_extension_control_path.pl
@@ -109,10 +109,10 @@ is($ret, "t",
"\$system extension is shown correctly in pg_available_extensions");
$ret = $node->safe_psql('postgres',
- "set extension_control_path = ''; select count(*) > 0 as ok from pg_available_extensions where name = 'plpgsql'"
+ "set extension_control_path = ''; select location from pg_available_extensions where name = 'plpgsql'"
);
-is($ret, "t",
- "\$system extension is shown correctly in pg_available_extensions with empty extension_control_path"
+is($ret, "\$system",
+ "\$system location is shown correctly in pg_available_extensions with empty extension_control_path"
);
# Test with an extension that does not exists
--
2.50.1 (Apple Git-155)
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Avoid leaking system path from pg_available_extensions
@ 2026-05-26 10:02 Jim Jones <[email protected]>
parent: Chao Li <[email protected]>
1 sibling, 0 replies; 9+ messages in thread
From: Jim Jones @ 2026-05-26 10:02 UTC (permalink / raw)
To: Chao Li <[email protected]>; Matheus Alcantara <[email protected]>; +Cc: pgsql-hackers; Andrew Dunstan <[email protected]>
On 26/05/2026 09:14, Chao Li wrote:
> In theory, I’m not against the idea either. In practice, there are many hard-coded strings in the source tree, and I’m not sure where the right place would be to define this macro.
>
> Since this string is only used in get_extension_control_directories(), and now it is used three times, I defined it at the beginning of the function and undefined it at the end. Let’s see if there are any objections to that.
I don't feel strongly about it. I only brought it up because hardcoded
strings used in multiple places are usually a recipe for oversights and
painful debugging down the road. That said, as I mentioned, I understand
the argument that this is scoped to a single function, and the fact
they're pretty close to one another also makes it less likely to be
missed, but there is no guarantee it'll stay like that forever.
Thanks for the fix!
Best, Jim
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Avoid leaking system path from pg_available_extensions
@ 2026-05-26 13:29 Matheus Alcantara <[email protected]>
parent: Chao Li <[email protected]>
1 sibling, 0 replies; 9+ messages in thread
From: Matheus Alcantara @ 2026-05-26 13:29 UTC (permalink / raw)
To: Chao Li <[email protected]>; +Cc: Jim Jones <[email protected]>; pgsql-hackers; Andrew Dunstan <[email protected]>
On 26/05/26 04:14, Chao Li wrote:
>
>
>> On May 22, 2026, at 23:40, Matheus Alcantara <[email protected]> wrote:
>>
>> On 22/05/26 04:25, Jim Jones wrote:
>>> On 21/05/2026 17:12, Matheus Alcantara wrote:
>>>> I've reproduced the issue and the fix looks correct to me.
>>> same here, +1
>>
>> Thank you for also testing.
>>
>>> I was wondering if creating a constant for it would be, stylistically
>>> speaking, a cleaner solution. For instance:
>>> #define EXTENSION_SYSTEM_MACRO "$system"
>>> I realize that it's used only inside get_extension_control_directories()
>>> but since it is even mentioned in the docs, I guess it wouldn't be a bad
>>> idea.
>>
>> I'm not against it but I don't think that it's necessary since as you mention, only get_extension_control_directories() use.
>>
>
> In theory, I’m not against the idea either. In practice, there are many hard-coded strings in the source tree, and I’m not sure where the right place would be to define this macro.
>
> Since this string is only used in get_extension_control_directories(), and now it is used three times, I defined it at the beginning of the function and undefined it at the end. Let’s see if there are any objections to that.
>
> Please see the attached v2.
>
We have such pattern in other parts of the codebase (e.g
pg_resetwal.c), so it works for me.
Thanks for the patch.
--
Matheus Alcantara
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 9+ messages in thread
end of thread, other threads:[~2026-05-26 13:29 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-05-20 01:00 Avoid leaking system path from pg_available_extensions Chao Li <[email protected]>
2026-05-20 01:07 ` Chao Li <[email protected]>
2026-05-21 08:55 ` lu feng <[email protected]>
2026-05-21 15:12 ` Matheus Alcantara <[email protected]>
2026-05-22 07:25 ` Jim Jones <[email protected]>
2026-05-22 15:40 ` Matheus Alcantara <[email protected]>
2026-05-26 07:14 ` Chao Li <[email protected]>
2026-05-26 10:02 ` Jim Jones <[email protected]>
2026-05-26 13:29 ` Matheus Alcantara <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox