Re: Disable or remove 'drop' button on toolbar

On Fri, Oct 9, 2015 at 7:28 PM, Joseph Marlin <jmarlin@saucontech.com> wrote:
> Ah yes, indeed.
>
> Counterpoint would be that this is like detonation charges at the base of a bridge and then saying that the police
shouldsimply keep people away from the bomb. Why not just remove the explosives from such an easily reached place? 

That's exactly the point - you implement security at the base level
(taking the explosives away). In this case, that means not giving the
users roles on the database that allow them to drop anything they
shouldn't.

Implementing security at the client level is *never* correct. In this
case, the users could just use the query tool if they actually wanted
to bypass the missing drop option, or go get another client and
connect with that.

> I can see the argument both ways. It definitely would be better access control to give managers/non-developers a role
thatdoesn't allow modification. I'll look into a role. Thanks! 
>
> ----- Original Message -----
> From: "Colin Beckingham" <colbec@kingston.net>
> To: "Joseph Marlin" <jmarlin@saucontech.com>, pgadmin-support@postgresql.org
> Sent: Friday, October 9, 2015 2:14:43 PM
> Subject: Re: [pgadmin-support] Disable or remove 'drop' button on toolbar
>
>
> On 09/10/15 01:48 PM, Joseph Marlin wrote:
>> We give pgadmin3 to some managers and other non-developers to allow them to run reports and scripts that we
(development)write for them. 
>>
>> The ease of pressing the 'drop' button on the main toolbar makes me really worried, even with the confirmation
dialogue.Even I have accidentally clicked it a few times. I can't imagine why I'd even want such a convenient way to
dropour entire production schema. 
>>
>> Is there any way to remove this button from the toolbar, or disable it? I could then go remove it from all the
managers'installations (and mine!). 
>>
>> Thanks!
>> Joseph Marlin
>>
>>
>>
> One way would be to require the users to log in to the database under a
> special user/role where the permissions are specially crafted to ensure
> that they don't have permission to cause the damage you fear. This puts
> the onus on the backend (Postgresql), not the frontend (PgAdmin) You
> could argue that this is where the responsibility properly should be
> embedded, on the back end.
>
>
> --
> Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-support



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

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