On Friday, September 22, 2023, Dominique Devienne
wrote:
>
> Remember that I'm already connected in the "parent" process, to the DB.
> There aught to be a way to obtain a token from the DB via a connection,
> with a short duration, to supply to the exec'd PostgreSQL tools like psql
> or pg_dump,
On Fri, Sep 22, 2023 at 8:56 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > Once you have the password you should utilize the PGPASSWORD environment
> > variable to get it passed to psql. It doesn’t matter in the least how
> you
> > obtained that password in the first place.
>
> Keep in m
"David G. Johnston" writes:
> Once you have the password you should utilize the PGPASSWORD environment
> variable to get it passed to psql. It doesn’t matter in the least how you
> obtained that password in the first place.
Keep in mind that on many flavors of Unix, a process's environment
varia
On Fri, Sep 22, 2023 at 3:24 PM Dominique Devienne wrote:
> I'm talking of replacing using my tool then psql, with using my tool that
> forks psql.
I thought you were talking about forking the source code to write your
own psql, sorry about that.
It is clear to me that you mean Unix fork(2) and
On Friday, September 22, 2023, Dominique Devienne
wrote:
>
>
> I already told you my app is LIBPQ aware, including about PGPASSWORD and
> PGSERVICE.
> It's users who decide to use these mechanisms (which have plain-text
> passwords BTW...), not my tool.
> The same way PSQL prompts for a password w
Seems to me that your tool could set the env var that you want.
If you don't export it, I think it shouldn't "leak" but your child process
should get it as part of their environment.
On Fri, Sep 22, 2023 at 12:43 PM Dominique Devienne
wrote:
> On Fri, Sep 22, 2023 at 5:19 PM Luca Ferrari wrote:
On Fri, Sep 22, 2023 at 5:19 PM Luca Ferrari wrote:
> On Fri, Sep 22, 2023 at 3:24 PM Dominique Devienne
> wrote:
> You added information I was not aware before: you are dumping
> PostgreSQL to restore it into SQLite, while I was thinking you wanted
> to do some stuff with a PostgreSQL-to-Postgr
On Friday, September 22, 2023, Luca Ferrari wrote:
>
> > That's why I'm asking the community how best to the forked PSQL can
> connect w/o password prompting.
>
> psql and lipq can exploit .pgpass for exactly that aim: not messing
> around with passwords.
> Again, I would discourage you to fork p
On Fri, 22 Sept 2023 at 15:25, Dominique Devienne wrote:
> On Fri, Sep 22, 2023 at 12:45 PM Luca Ferrari wrote:
...
>> I think that forking a beast like psql will make you incurring into a
>> lot of security problems that are worst your "password leak".
> I'm sorry, but this doesn't make sense to
On Fri, Sep 22, 2023 at 10:56 AM Luca Ferrari wrote:
> On Thu, Sep 21, 2023 at 7:46 PM Dominique Devienne
> wrote:
> > and I also need to run some PSQL \commands and SQL to config PSQL
> correctly
> > for the context our tool was run with (i.e. our tool's own CLI options).
> >
>
> Isn't .psqlrc
On Fri, Sep 22, 2023 at 12:45 PM Luca Ferrari wrote:
> On Fri, Sep 22, 2023 at 12:13 PM Dominique Devienne
> wrote:
> > So my question is how I pass the password my tool already own, to the
> forked PSQL,
> > w/o that password leaking. I could pass it on the command-line, but that
> would be lea
On Fri, Sep 22, 2023 at 12:13 PM Dominique Devienne wrote:
> So my question is how I pass the password my tool already own, to the forked
> PSQL,
> w/o that password leaking. I could pass it on the command-line, but that
> would be leaking
> it to the `ps` command (and in various other places).
On Thu, Sep 21, 2023 at 7:46 PM Dominique Devienne wrote:
>
> Hi. To administer our PostgreSQL-based system, we have custom tools
> to manage the schemas, load data, etc... Including a versatile CLI tool.
>
> But that tool is special purpose, while sometimes we want/need the general
> purpose PSQL
Hi. To administer our PostgreSQL-based system, we have custom tools
to manage the schemas, load data, etc... Including a versatile CLI tool.
But that tool is special purpose, while sometimes we want/need the general
purpose PSQL. But because our ROLE and SCHEMA names are rather long
and unwieldly,
14 matches
Mail list logo
