Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tDxHz-004GtT-Lq for pgsql-admin@arkaria.postgresql.org; Thu, 21 Nov 2024 02:51:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tDxHy-00BRhF-C0 for pgsql-admin@arkaria.postgresql.org; Thu, 21 Nov 2024 02:51:26 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tDxHx-00BRf5-TT for pgsql-admin@lists.postgresql.org; Thu, 21 Nov 2024 02:51:25 +0000 Received: from mail-oa1-x31.google.com ([2001:4860:4864:20::31]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tDxHv-0032IY-OD for pgsql-admin@lists.postgresql.org; Thu, 21 Nov 2024 02:51:25 +0000 Received: by mail-oa1-x31.google.com with SMTP id 586e51a60fabf-27b7a1480bdso294014fac.2 for ; Wed, 20 Nov 2024 18:51:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732157482; x=1732762282; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=atI08sMDtJbwV7H1PZLweCwJqPtd0Tn29H/JVBubiwM=; b=OKFSt/VLNITt9XgcFOU2JOcsMhUNff4+C9YRfUA9gcvjkmFV8ZknaWTD6EIF9uC4mn 3WheTlkaw8nSd/FBbMNtwSMFo3pDMLxKzRMwifdKwuqLkGa0p/80hnIF6Lj4Hlr0gJoF UQYTAkd32w2rPmsL+23DF0KBBsHlk1YbbKIkDREA2ebpTB9JMSzeGWR3hh0kfrxCgxuK lK1iFFmP0szaI/06xtYxGUAOjkVfn6d8j8hSA3bEbEFoAjZsUNu7EItx6X2W+A5XOE3L Q/7/+T4+LUc7uHwtwXf/z2ZwB2dZtssczVjRU8ejhvpBL2HeyTQ63VWUdizr6VIdKsDV rHwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732157482; x=1732762282; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=atI08sMDtJbwV7H1PZLweCwJqPtd0Tn29H/JVBubiwM=; b=HLGJJVM+DkTDUhx15APSiLAg6vG1cmqH00dMyX/gipB/5D8sNCXIUokqBbmzIjXp9p yJRQiVYWq5gOxsi1Q0U/qN/DAKGT4I3keLO8v9JmUVOSpMWFJ+yOW1gsvniHG3Gj5A6k H7O5lkSa7S1xzmSB2rRCtQ7u027xasZVIz80+m84yVx/d2JCP2ksCJkT+pZEmT6ycJqx 1sE17OAxKMDj3KV5Q44LW/IB/BmlF8RRo10LzP+uV6pawe3LV4RZ8fB3AJih0LmPXMHM m1d1gMxzzGteQb3tWBGGn52XpKSIktIFcZmzFzgirKjmfVCPWd/YpNgXKF+3SWGR5Z/P 7obQ== X-Forwarded-Encrypted: i=1; AJvYcCXoyPgmFcRUUGaMBBJLijjyrNTdrLZUtZmUCa/9V+U5ekC7DKjdEsCApUU4kSd9Y6cgBl7NWX5CNpaMUw==@lists.postgresql.org X-Gm-Message-State: AOJu0Yxd4NLDLhhIKSt7msDiKbZbVUdP4mFe2weG1QQHGSi78XlSBPLY 5NLzMl0VEfBbS+zciPYBRd/FgGhFZULAw6PdTEVhiQ18EH5327PQ7R/MVtLDtHgUIBalJB5TjRE MvDUYE47KDdB7iuEonAGImPRXiBo= X-Google-Smtp-Source: AGHT+IH9kMIIqAXvBDXJiGYM/Aexfb4fZ1Zb9wwMSm1dPpzUOcVLk2onNXPCws9lWp0Dqcm/dhS8b49Gm5VDPXH+dfk= X-Received: by 2002:a05:6871:7d84:b0:296:e46a:6e5e with SMTP id 586e51a60fabf-296e46aafa3mr3385631fac.21.1732157482030; Wed, 20 Nov 2024 18:51:22 -0800 (PST) MIME-Version: 1.0 References: <74CE8CC4-3A14-4A64-AF90-9514E27CC56B@elevated-dev.com> In-Reply-To: From: "David G. Johnston" Date: Wed, 20 Nov 2024 19:50:43 -0700 Message-ID: Subject: Re: Disable Save results to file button To: Srini Genji Cc: Scott Ribe , pgsql-admin@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000695cc606276357f2" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000695cc606276357f2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 20, 2024 at 7:38=E2=80=AFPM Srini Genji = wrote: > > This is coming mainly from security to avoid users downloading huge > datasets containing sensitive data in to their machine > > I appreciate the desire here, and it isn't unreasonable, but it is also technically nearly impossible. If you have given a person credentials, network access, and the relevant database permissions to see all of that data they will be able to make a copy of it that you do not control. While marginal improvements are possible, the cost of doing them (and available mitigations) discourages people from working on such patches in favor of other things. If this is a security risk you need to mitigate in PostgreSQL you probably need to implement a solution where the user does not directly have credentials for the database, but asks some proxy to access the database on their behalf (e.g., a webapp) and in that proxy you institute such policies. I feel like some tools and extensions in this area likely exist, though I am not personally familiar with any of them if that is so. Yes, ideally pgAdmin, if you can otherwise lock down their machine and prohibit any other software from being run as well as ensure their credentials only are usable on that machine (both doable propositions I daresay) would fill in the missing piece and provide a viewer-only option. Or maybe just run it on a server where the local machine isn't accessible to the user... David J. (p.s., this is the admin mailing list for the PostgreSQL server, not the mailing list for the third-party pgAdmin product. If you have a requirement to use pgAdmin you may wish to converse with that team in their own channels.) --000000000000695cc606276357f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 20, 2024 at 7:38=E2=80=AFPM Srini Genji <srini.genji@gmail.com> wrote:=

This is coming= mainly from security to avoid users downloading huge datasets containing s= ensitive data in to their machine


I appreciate the desire here, and it isn't= unreasonable, but it is also technically nearly impossible.=C2=A0 If you h= ave given a person credentials, network access, and the=C2=A0relevant datab= ase permissions to see all of that data they will be able to make a copy of= it that you do not control.=C2=A0 While marginal improvements are possible= , the cost of doing them (and available mitigations) discourages people fro= m working on such patches in favor of other things.

If= this is a security risk you need to mitigate in PostgreSQL you probably ne= ed to implement a solution where the=C2=A0user does not directly have crede= ntials for the database, but asks some proxy to access the=C2=A0database on= their behalf (e.g., a webapp) and in that proxy you institute such policie= s.=C2=A0 I feel like some tools and extensions in this area likely exist, t= hough I am not personally familiar with any of them if that is so.
=
Yes, ideally pgAdmin, if you can otherwise lock down their mac= hine and prohibit any other software from being run as well as ensure their= credentials only are usable on that machine (both doable propositions I da= resay) would fill in the missing piece and provide a viewer-only option.=C2= =A0 Or maybe just run it on a server where the local machine isn't acce= ssible to the user...

David J.

(= p.s., this is the admin mailing list for the PostgreSQL server, not the mai= ling list for the third-party pgAdmin product.=C2=A0 If you have a requirem= ent to use pgAdmin you may wish to converse with that team in their own cha= nnels.)
--000000000000695cc606276357f2--