Re: pgAdmin4 4.8 Kubuntu issues

On Wed, Jun 5, 2019 at 7:29 PM richard coleman <rcoleman(dot)ascentgl(at)gmail(dot)com>
wrote:

>
> All passwords are stored in files of one sort or another. Hopefully those
>> files are effectively encrypted (assuming of course that you had even had
>> pgAdmin4 save your passwords to begin with).
>>
>
Sure, in pgAdmin 4 they are (unlike pgAdmin 3 which used PostgreSQL's
.pgpass files which are plain text). However, the problem is that unless
the key to encrypt/decrypt those passwords is stored externally (e.g. in
the users brain, or on a Ubikey or similar), it is also in a file.

> Now you may have a VPN, but you also may use the same password for
>> different things, or other people might use servers that are less hard to
>> reach.
>> The same sort of people who use the same password for a number of
>> things are just going to use that self same password as their *master
>> password* in pgAdmin4.
>>
>
Sure - however, I'm not ever going to make the default security in pgAdmin
cater to people who do stupid things like that, or just assume that people
are already doing stupid things so we shouldn't bother. We will always
strive to be secure by default, within the bounds of reasonable user
experience.

> How? pgAdmin has no way of doing that over what is essentially a web
>> application - and even if it did, allowing a remotely accessible
>> application (particularly one in which external programs can be configured
>> and executed by users) to modify it's own configuration is a *really* bad
>> idea.
>> Well for a start Edge uses Microsoft's user credentials as a master
>> password. Any number of applications can access files in a *protected
>> area *and prompt for a sudo/administrator credential.
>>
>
We could do that too. Assuming users were happy to setup a Kerberos
infrastructure. Otherwise, we'd need to rely on browser password saving
which isn't always reliable. The browser intentionally doesn't allow us to
access locally held credentials as that would be massively insecure.

> As for the choice to make pgAdmin4 a python version of phpPgAdmin,
>> there's been a lot of discussion, most of it not very favorable. I
>> guess you can chalk this up to one more reason converting pgAdmin from an
>> application to a *web app* was probably not the best idea.
>>
>
Funny that, whilst there certainly have been people who didn't like the
change, the *vast* majority of feedback I receive has been positive since
we ironed out the very early performance issues. Downloads are up massively
as well, and that's before you count the Docker distro that didn't exist
with pgAdmin 3, which has been over 5M pulls for quite some time now (I
don't know the banding of Dockers numbers - I assume it'll go to 10M+ at
some point).

Regardless, I'm happy with the change, and I'm happy in the knowledge that
most users seem to agree. Those that don't are welcome to use the LTS
version of pgAdmin 3 if they prefer, or other tools. It's a free world (for
the most part) - people can and should use what they find most productive
and useful for them. I will carry on working on and providing (for free)
the tools that interest me.

>
>>> So basically what we have is a *major* UI change (users are literally
>>> locked out of the application) caused by upgrading a minor version level
>>> (4.7 to 4.8) with no simple way to revert the behavior all for a dubious
>>> increase in security.
>>>
>>
>> I don't wish to be rude, but it's clear you don't fully appreciate the
>> possible risks here - and I really don't agree that being asked for a
>> password once when the application starts (not an instance of the UI, but
>> the server itself, which may support a number of concurrent or intermittent
>> sessions) is a major UI change. Not that I'd recommend it, but you could
>> have an extremely short password that you type and then press enter. You
>> could even ask your browser to save that password if you're less concerned
>> about security, and then we're talking about *a single mouse click* at the
>> start of your day, or if you're like me, start of your week.
>> So you don't deny that 4.8 radically changed it's behavior, without
>> warning, from 4.7. You then seek to minimize the impact this has on people
>> by undermining the reason for implementing it in the first place. Let's see
>> if I am understanding your argument:
>>
>
You're obviously not. I don't deny there is a minor change in workflow,
which can be trivially disabled (hopefully more since now I've improved the
docs based on your feedback).

>
> - You *must *force end users to start using a master password because
> they just *don't understand* the security risks of not using one.
>
> Nope. I said (intended respectfully), that I didn't believe you understood
the attack vectors we were discussing. That is absolutely *not* the same as
saying "users" don't understand in general.

>
> - In order to force the issue, you lock most of the functionality
> behind the "Master Password" dialog box until they either scour the
> internet looking for a way to turn off this *feature* or submit and
> enter a master password.
>
> As noted twice now, I've updated the documentation based on your feedback.

>
> - When someone complains about this heavy handed behavior your
> *solution* is to
> - use an *extremely short *password
> - have* your browser* store your password
>
> Nope again. I specifically said that I didn't recommend doing that, I was
just pointing out that you could if you chose to.

>
> - point out that you keep pgAdmin4 running for days or weeks at a
> time, so it's *no big deal *
>
> Sure. Even if I were restarting a couple of times a day, I don't believe
entering a password each time is a major inconvenience. It would be such an
insanely miniscule amount of typing/clicking compared to everything else I
do in a day that I couldn't begin to count it.

Think about it; I've probably spent an hour or so in total on this
discussion so far. Even if I took 5 seconds to enter the password (It's
probably way less than that), that's 720 times I could have entered that
password.

> So, the users *must *use a master password, because *security. *If
> you find it too burdensome then just use it in a very *insecure* way.
>
> How about;
>
> Don't spring major changes like this on users during a *minor* update
>
>
A major update for pgAdmin is one that radically changes the entire
application design or architecture. Minor updates constantly add both small
and large features.

> Make it opt-*in* not opt-*out*
>
>
Not going to happen.

> Make if very *easy* for users to turn this feature on or off
>
>
Docs have been improved, but it's not going to become a preference for
reasons already discussed (at least not without a complete overhaul of the
preferences system to allow admins to lock users out of certain changes).

> Protect the absolute *minimum* with this feature, not the entire
> application.
>
>
It could be improved to only prompt for the password the first time a user
tries to connect to a server with a saved password. I suspect that would
only make a difference for a very small number of people though, as most
will either save all or none of their passwords (and the latter group might
have password saving disabled in the application config anyway).

>
> Hardly a major inconvenience.
>>
>> And as for your comment about letting pgAdmin run for days/weeks on
> your machine, congratulations. When I leave pgAdmin running for more than
> a couple of hours it becomes unresponsive. Not the UI, that works just
> fine, but running any queries will take forever (as in they will
> literally never finish, just grey out the query tool window). For example
> SELECT * FROM <table> LIMIT 1; will never finish, but as soon as I shut
> down the server (pgAdmin4 not the database server) and restart it will
> complete instantaneously. So I need to restart pgAdmin4 the *server* many
> times a day.
>

Have you logged an issue about that with logs etc? If that is what happens
for you, then I'd certainly like to resolve that.

> I really do hope you'll reconsider this ill-implemented *feature.*
>

I've already reconsidered it - I always reconsider things when we get user
feedback. In this case though, I don't agree with your arguments. The extra
security adds a trivial overhead to user workflow, and those that don't
want it can disable it completely with a couple of minutes of effort, all
whilst allowing sysadmins to enforce the use of the feature if they want.

I've said my piece on the topic now - on to other subjects.

>
> rik.
>
>> Yes, I think I have been quite restrained in my assessment.
>>>
>>> Thanks,
>>>
>>> rik.
>>>
>>>
>>>
>>> On Wed, Jun 5, 2019 at 10:59 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>
>>>> Richard,
>>>>
>>>> On Wed, Jun 5, 2019 at 3:22 PM richard coleman <
>>>> rcoleman(dot)ascentgl(at)gmail(dot)com> wrote:
>>>>
>>>>> Dave,
>>>>>
>>>>> And where would *that* be? pgAdmin4 the executable and the shared
>>>>> library is located in /usr/bin/. There are *no* entries in /etc/ for
>>>>> pgAdmin4. There is a pgadmin4.db in /home/u/.pgadmin/ but *no* config
>>>>> files of any kind there either.
>>>>>
>>>>
>>>> I have no idea, I don't use Ubuntu or any of it's derivatives and don't
>>>> know where it installs. Have you tried searching for config.py? That is
>>>> *not* optional, and must exist.
>>>>
>>>>
>>>>> So it's looking like the only way to actually *use *the current
>>>>> version of pgAdmin4 is to create an undocumented file (the help page says
>>>>> you can use config.py as a reference, but guess what? That file doesn't
>>>>> exist either.) in an unknown location, and manually add the magic string;
>>>>>
>>>>> "*MASTER_PASSWORD_REQUIRED=False"*
>>>>>
>>>>>
>>>> I think that's a little hyperbolic don't you? It works as intended,
>>>> with no changes required if you set the password and re-enter it when you
>>>> restart pgAdmin. You only need to modify anything if you want to change the
>>>> behaviour.
>>>>
>>>> And to be clear; if config.py is not present on your system, then there
>>>> is no way pgAdmin will even start, let alone work.
>>>>
>>>>
>>>>>
>>>>> I get *why* you added this feature, but I think it was implemented *completely
>>>>> backwards*. Instead of making *every* end user jump through these
>>>>> ridiculous hoops just to *continue* to use pgAdmin4 as they had been
>>>>> up to this point, a better option would be to allow security conscious sys
>>>>> admins to add the configuration:
>>>>>
>>>>> "*MASTER_PASSWORD_REQUIRED=True"*
>>>>>
>>>>> to a non-user writable configuration file. In that way the vast
>>>>> majority of people running pgAdmin4 can continue to do so and the few that
>>>>> wanted/needed the added security could do so as well.
>>>>>
>>>>
>>>> That is not how security works. Without the master password feature,
>>>> there are possible attack vectors in which a stored password could be
>>>> accessed by third parties. We aim for secure by default; if you don't care
>>>> about the risk, then you can actively choose to run in a less secure way.
>>>>
>>>>
>>>>>
>>>>>
>>>>> So, now I'm using dBeaver as I *can't* disable the Master Password
>>>>> dialog box and pgAdmin4 won't let me *do* anything.
>>>>>
>>>>> Any other thoughts? Anyone?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> rik.
>>>>>
>>>>> On Wed, Jun 5, 2019 at 10:03 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 5, 2019 at 2:44 PM richard coleman <
>>>>>> rcoleman(dot)ascentgl(at)gmail(dot)com> wrote:
>>>>>>
>>>>>>> Dave,
>>>>>>>
>>>>>>> Sorry, but after an e*xhaustive* search of the several terabytes on
>>>>>>> my machine, there is *no* config_local.py file. Do you have any
>>>>>>> idea where it's supposed to be located?
>>>>>>>
>>>>>>
>>>>>> You need to create it if it doesn't exist, in the same directory as
>>>>>> pgAdmin's config.py.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> rik.
>>>>>>>
>>>>>>> On Wed, Jun 5, 2019 at 9:30 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Jun 5, 2019 at 1:16 PM richard coleman <
>>>>>>>> rcoleman(dot)ascentgl(at)gmail(dot)com> wrote:
>>>>>>>>
>>>>>>>>> Cherio,
>>>>>>>>>
>>>>>>>>> I am sorry to inform you, but there is *no* mention of "config_local.py"
>>>>>>>>> on that page, nor any indication of where I would find it.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://www.pgadmin.org/docs/pgadmin4/4.x/desktop_deployment.html#configuration
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> rik.
>>>>>>>>>
>>>>>>>>> On Tue, Jun 4, 2019 at 5:06 PM Cherio <cherio(at)gmail(dot)com> wrote:
>>>>>>>>>
>>>>>>>>>> Put "MASTER_PASSWORD_REQUIRED = False" line into your
>>>>>>>>>> "lib/python?.?/site-packages/pgadmin4/config_local.py". This is in the
>>>>>>>>>> docs:
>>>>>>>>>> https://www.pgadmin.org/docs/pgadmin4/dev/master_password.html
>>>>>>>>>>
>>>>>>>>>> On Tue, Jun 4, 2019 at 4:41 PM richard coleman <
>>>>>>>>>> rcoleman(dot)ascentgl(at)gmail(dot)com> wrote:
>>>>>>>>>>
>>>>>>>>>>> To whomever,
>>>>>>>>>>>
>>>>>>>>>>> Running a newly update pgAdmin 4 version 4.8 on my Kubuntu box.
>>>>>>>>>>> There are a couple of glaring issues.
>>>>>>>>>>>
>>>>>>>>>>> First: It keeps prompting to; "Set Master Password"
>>>>>>>>>>> I don't want to set another password that I'll just end up
>>>>>>>>>>> forgetting.
>>>>>>>>>>>
>>>>>>>>>>> Second: When I click the "?" button on that dialog box it takes
>>>>>>>>>>> me to this page:
>>>>>>>>>>> "http://127.0.0.1:33681/help/help/master_password.html"
>>>>>>>>>>> Which returns "404 Not Found"
>>>>>>>>>>>
>>>>>>>>>>> Hopefully there is a simple solution to these issues.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> rik.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Dave Page
>>>>>>>> Blog: http://pgsnake.blogspot.com
>>>>>>>> Twitter: @pgsnake
>>>>>>>>
>>>>>>>> EnterpriseDB UK: http://www.enterprisedb.com
>>>>>>>> The Enterprise PostgreSQL Company
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Dave Page
>>>>>> Blog: http://pgsnake.blogspot.com
>>>>>> Twitter: @pgsnake
>>>>>>
>>>>>> EnterpriseDB UK: http://www.enterprisedb.com
>>>>>> The Enterprise PostgreSQL Company
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Dave Page
>>>> Blog: http://pgsnake.blogspot.com
>>>> Twitter: @pgsnake
>>>>
>>>> EnterpriseDB UK: http://www.enterprisedb.com
>>>> The Enterprise PostgreSQL Company
>>>>
>>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company