On Tue, Jul 24, 2018 at 12:25:31PM +0200, Marco van Eck wrote:
> Indeed having unencrypted password lying (.pgpass or PGPASSWORD or -W)
> around is making my auditors unhappy, and forcing me to enter the password
> over and over again. With a simple test it seems the password entered by
> the user
On Wed, Aug 1, 2018 at 05:33:39PM +0200, Marco van Eck wrote:
> After explaining the patch to a college we identified potentially execution of
> another user when it is defined in as a command parameter. To protect agains
> it
> I've removed the possibility to pass the 'passcommand'. With the
On Thu, 2 Aug 2018 at 10:41, I wrote:
> Perhaps you could make your auditors happier by restricting that user's
> permissions to only run a defined function, and make that function do the
> work that the automation script wants? So even if the attacker can access
> the password he will still only
On Tue, 24 Jul 2018 at 11:25, Marco van Eck wrote:
> Indeed having unencrypted password lying (.pgpass or PGPASSWORD or -W)
> around is making my auditors unhappy,
>
With the greatest of respect, perhaps you need to get auditors who
understand crypto better.
Having a user that has the
Hello.
I have had complaints several times on lack of this kind of
feature.
At Wed, 1 Aug 2018 17:33:39 +0200, Marco van Eck wrote
in
> After explaining the patch to a college we identified potentially execution
> of another user when it is defined in as a command parameter. To protect
>
After explaining the patch to a college we identified potentially execution
of another user when it is defined in as a command parameter. To protect
agains it I've removed the possibility to pass the 'passcommand'. With the
result libpq only allows the PGPASSCOMMAND environment variable, which can
Marco van Eck writes:
> Indeed having unencrypted password lying (.pgpass or PGPASSWORD or -W)
> around is making my auditors unhappy, and forcing me to enter the password
> over and over again. With a simple test it seems the password entered by
> the user also stays in memory, since it is able
Indeed having unencrypted password lying (.pgpass or PGPASSWORD or -W)
around is making my auditors unhappy, and forcing me to enter the password
over and over again. With a simple test it seems the password entered by
the user also stays in memory, since it is able to reset a broken
connection.
On Tue, Jul 24, 2018 at 2:10 PM, Craig Ringer wrote:
>> Grabbing it from a process's memory is a bit harder than grabbing contents
>> of a file, but not much harder. If the agent is remote then that's harder,
>> but you can just ask the script to decrypt the pgpass for you, so again, not
>> much
On 24 July 2018 at 05:53, Jeff Janes wrote:
> On Wed, Jul 18, 2018 at 5:52 PM, Tom Lane wrote:
>
>> Thomas Munro writes:
>> > On Thu, Jul 19, 2018 at 5:46 AM, Marco van Eck
>> wrote:
>> >> Since .pgpass files contain plain-text passwords, I searched for an
>> >> alternative.
>> >> In the
On Wed, Jul 18, 2018 at 5:52 PM, Tom Lane wrote:
> Thomas Munro writes:
> > On Thu, Jul 19, 2018 at 5:46 AM, Marco van Eck
> wrote:
> >> Since .pgpass files contain plain-text passwords, I searched for an
> >> alternative.
> >> In the attached patch I've added the possibility to run a command
On Wed, Jul 18, 2018 at 11:19 PM, Tom Lane wrote:
> Sorry, I don't buy that line of argument. The *only* reason for this
> feature to exist is if it allows ready creation of security solutions
> that are actually more secure than a non-world-readable .pgpass file.
> That's a much higher bar than
Sorry Tom (and others), I didn't notice my change affected libpq. Though I
would really like the possibility to have an encrypted way of presenting
the pgpassfile. Would it be more secure if the script / command is passed
as a compile option to libpg and the variable only contains the filename of
Isaac Morland writes:
>>> It would also provide a *very* fertile source of shell-script-injection
>>> vulnerabilities. (Whaddya mean, you tried to use a user name with a
>>> quote mark in it?)
> If I understand the proposal correctly, the pgpass program would run on the
> client, invoked by
On 20 July 2018 at 17:22, Tels wrote:
> Moin,
>
> > It would also provide a *very* fertile source of shell-script-injection
> > vulnerabilities. (Whaddya mean, you tried to use a user name with a
> > quote mark in it?)
>
> Little Bobby Tables, we call him. :)
>
> I'm also concerned that that
Moin,
On Wed, July 18, 2018 7:25 pm, Tom Lane wrote:
> Alvaro Herrera writes:
>> Seems to me that passing %-specifiers to the command would make it more
>> useful (%u for "user", "host" etc) -- your command could refuse to give
>> you a password for the superuser account for instance but grant
On Thu, Jul 19, 2018 at 5:19 AM Tom Lane wrote:
> "Joshua D. Drake" writes:
> > On 07/18/2018 04:25 PM, Tom Lane wrote:
> >> This is exactly the kind of area in which I'm concerned for the
> >> possibility of sloppily-written scripts being a net negative for
> >> security.
>
> > Although I
"Joshua D. Drake" writes:
> On 07/18/2018 04:25 PM, Tom Lane wrote:
>> This is exactly the kind of area in which I'm concerned for the
>> possibility of sloppily-written scripts being a net negative for
>> security.
> Although I appreciate the concern, can we not worried about this? Your
>
On 07/18/2018 04:25 PM, Tom Lane wrote:
Alvaro Herrera writes:
Seems to me that passing %-specifiers to the command would make it more
useful (%u for "user", "host" etc) -- your command could refuse to give
you a password for the superuser account for instance but grant one for
a read-only
Alvaro Herrera writes:
> Seems to me that passing %-specifiers to the command would make it more
> useful (%u for "user", "host" etc) -- your command could refuse to give
> you a password for the superuser account for instance but grant one for
> a read-only user.
It would also provide a *very*
On 2018-Jul-18, Marco van Eck wrote:
> Since .pgpass files contain plain-text passwords, I searched for an
> alternative.
> In the attached patch I've added the possibility to run a command to
> produce the content of the pgpass file, in exactly the same format. In this
> way I could use gpg or
On Thu, Jul 19, 2018 at 9:52 AM, Tom Lane wrote:
> Thomas Munro writes:
>> On Thu, Jul 19, 2018 at 5:46 AM, Marco van Eck
>> wrote:
>>> Since .pgpass files contain plain-text passwords, I searched for an
>>> alternative.
>>> In the attached patch I've added the possibility to run a command to
Thomas Munro writes:
> On Thu, Jul 19, 2018 at 5:46 AM, Marco van Eck wrote:
>> Since .pgpass files contain plain-text passwords, I searched for an
>> alternative.
>> In the attached patch I've added the possibility to run a command to produce
>> the content of the pgpass file, in exactly the
> On Jul 18, 2018, at 14:33, Thomas Munro wrote:
> Here you side step those questions completely and make that the end
> user's problem. I like it.
+1. This is a clever solution, since any kind of key vault or other system
could be dropped in there.
--
-- Christophe Pettus
On Thu, Jul 19, 2018 at 5:46 AM, Marco van Eck wrote:
> Since .pgpass files contain plain-text passwords, I searched for an
> alternative.
> In the attached patch I've added the possibility to run a command to produce
> the content of the pgpass file, in exactly the same format. In this way I
>
Hi,
Since .pgpass files contain plain-text passwords, I searched for an
alternative.
In the attached patch I've added the possibility to run a command to
produce the content of the pgpass file, in exactly the same format. In this
way I could use gpg or any other command to decrypt a pgpass file.
26 matches
Mail list logo
