Thread: Disable or remove 'drop' button on toolbar
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
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.
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? 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.
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
On 10/12/2015 3:48 AM, Dave Page wrote: > 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 have superuser rights and sometimes mis-click. I'm also concerned with the "Delete/Drop" right underneath "Disconnect database" in the context menu. The confirmation popup has saved me many times over the years. If it were an option I would disable it. Just my 2 cents... -- Stephen
On 12/10/15 04:09 AM, Stephen Cook wrote: > On 10/12/2015 3:48 AM, Dave Page wrote: >> 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 have superuser rights and sometimes mis-click. > > I'm also concerned with the "Delete/Drop" right underneath "Disconnect > database" in the context menu. The confirmation popup has saved me many > times over the years. > > If it were an option I would disable it. Just my 2 cents... > > > -- Stephen While it is quite true that mis-clicks are a possibility (I'm sure we have all seen the situation where an overloaded system can't quite keep up with screen coordinates and what we think we are clicking is not what gets activated) I agree with Dave that the backend protection comes first. It might make sense to activate/deactivate buttons in a client based on detected backend permissions, but this leaves the client user to use whatever role has the permissions required to achieve the intended tasks.
Hello all, 12.10.2015 11:27, Colin Beckingham wrote: [...] >> I'm also concerned with the "Delete/Drop" right underneath "Disconnect >> database" in the context menu. The confirmation popup has saved me many >> times over the years. >> >> If it were an option I would disable it. Just my 2 cents... >> >> >> -- Stephen > While it is quite true that mis-clicks are a possibility (I'm sure we > have all seen the situation where an overloaded system can't quite keep > up with screen coordinates and what we think we are clicking is not what > gets activated) I agree with Dave that the backend protection comes > first. It might make sense to activate/deactivate buttons in a client > based on detected backend permissions, but this leaves the client user > to use whatever role has the permissions required to achieve the > intended tasks. Ideally, it might be indeed nice to have a global UI preference setting for that, named like "Protection against ocasional destructive mis-clicks" with some levels like "Ask for confirmation before taking destructive action" and "Disable potentially destructive buttons and menu items". With a reasonable default chosen, that probably wouldn't hurt anybody, and might eventually save some :) Thank you, Nikolai
It’s integral to have a complete User Management Module with a Permissions Management System in every admin panel otherwiseyour web application is destined to a fail. Regards, Tabish Naeem MI Dynamics - Offshore Software Development Tabish.naeem@midgr.com www.midgr.com -----Original Message----- From: pgadmin-support-owner@postgresql.org [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of Dave Page Sent: Monday, October 12, 2015 12:49 PM To: Joseph Marlin Cc: Colin Beckingham; pgAdmin Support Subject: Re: [pgadmin-support] 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 meansnot 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 theyactually 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 -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support