On Tue, Aug 14, 2018 at 03:59:19PM -0400, Bruce Momjian wrote:
> On Fri, Aug 10, 2018 at 04:06:40PM -0400, Benedict Holland wrote:
> > I also would take Bruce's comment with a massive grain of salt. Everything
> > that
> > everyone does on a database is logged somewhere assuming proper logging.
>
On Fri, Aug 10, 2018 at 04:06:40PM -0400, Benedict Holland wrote:
> I also would take Bruce's comment with a massive grain of salt. Everything
> that
> everyone does on a database is logged somewhere assuming proper logging. Now
> do
> you have the person-power to go through gigs of plain text lo
On Fri, Aug 10, 2018 at 10:34:26PM -0400, Rui DeSousa wrote:
> With that logic then you should use flat files for encrypted data and
> unencrypted data. It’s what was done many moons ago; and its unstructured
> haphazard approach gave rise to RDBMS systems.
>
> You cannot say that encrypted data
> On Aug 10, 2018, at 7:21 PM, Benedict Holland
> wrote:
>
> Oh this is an easy one. There are simpler solutions for PITR. Also, a PITR is
> a very specific case of a database use, if it even uses one. Generally
> speaking, you would not want to keep encrypted data within a database. There
Oh this is an easy one. There are simpler solutions for PITR. Also, a PITR
is a very specific case of a database use, if it even uses one. Generally
speaking, you would not want to keep encrypted data within a database.
There simply isn't a need for it. Just use a file or a folder. You can't do
any
> On Aug 6, 2018, at 10:45 AM, Bear Giles wrote:
>
> then it's reasonable to ask if storing the information in a relational
> database is the best approach.
Why? Just because its encrypted doesn’t mean it shouldn’t be stored in the
database. What about PITR, how would that be handled? You b
The short answer I will provide from my experience is that you can't do it.
Your DBA will have access to just about anything across all tables and
databases.
The longer answer are ones that others have pointed out. If a DBA should be
restricted from tables, they probably shouldn't be your DBA. You
On Mon, Aug 6, 2018 at 06:19:55AM -0700, David G. Johnston wrote:
> On Monday, August 6, 2018, wrote:
>
>
> I have a request for revoking the access to user's data from DBA-user.
> I think the request is right because users should be the only ones can
> access their data.
>
>
> Us
Very true - when you've been hitting credit card and health care nails you
tend to forget that not every problem requires the same level of hammer!
Ask me what's required for anything in the Hadoop ecosystem. shudder.
However it's also true that there's no such thing as a site or database too
smal
Hi all,
Thanks for giving a lot of points of view.
I know superuser can not be revoked apart of privileges,
because it does not like nosuperusers who's privileges can be made from GRANT
statement.
As you all mentioned, I will re-check more about our system designation.
I am inclined to encry
bejita0...@yahoo.co.jp writes:
> Hello,
>
> I am a newbie DBA.
>
> I have a request for revoking the access to user's data from DBA-user.
> I think the request is right because users should be the only ones can access
> their data.
> But DBA-user also need full access to the other data? It mean
Bejita,
I suggest you step back and think about the problem from the point of view of
the desired security outcome — that of protecting data from improper use by
administrators. Some of the elements that (to my mind) ought to be part of
achieving that outcome are:
1. Determine and document yo
I should clarify something I said above - I know that some data must be
encrypted within the database. My point was that during the design phase
you should take the schema, cross out all columns that will be encrypted,
and ask what's left. If it's nothing but the primary key and things you'll
never
Thanks, I didn't realize that this was handled by a flag instead of just
the standard permissions.
On Mon, Aug 6, 2018 at 7:43 AM, Tom Lane wrote:
> Bear Giles writes:
> > In postgresql the equivalent user is 'postgres'. Nobody should ever be
> > logged in as that user once you've created the i
Encrypting data within the database(*) severely limits its usability - you
can't use it in queries, etc. In some cases it's not a problem since you'll
never want to use it in a query anyway, or you can use a proxy(**). But as
a general rule I think if you're encrypting much of your data then a
trad
Bear Giles writes:
> In postgresql the equivalent user is 'postgres'. Nobody should ever be
> logged in as that user once you've created the initial user(s). What
> postgresql calls a 'superuser' is just a user with a few permissions set by
> default. It's easy to grant the same privileges to any
I think you may be conflating two things.
The "superuser" (or root) in an operating system is a special user (with
uid = 0 in unix/linux systems) that bypasses many checks. Ideally sysadmins
and regular users will never log in as root - they'll either use the
existing privilege framework (e.g., gr
On Monday, August 6, 2018, wrote:
>
> I have a request for revoking the access to user's data from DBA-user.
> I think the request is right because users should be the only ones can
> access their data.
>
User then needs to encrypt data prior to storing it. Superuser can still
access the data b
Hello
From: bejita0...@yahoo.co.jp [mailto:bejita0...@yahoo.co.jp]
Sent: Montag, 6. August 2018 11:49
To: pgsql-ad...@lists.postgresql.org; pgsql-general@lists.postgresql.org
Subject: How to revoke privileged from PostgreSQL's superuser
Hello,
I am a newbie DBA.
I have a re
ita0...@yahoo.co.jp"
Reply-To: "bejita0...@yahoo.co.jp"
Date: Monday, August 6, 2018 at 3:19 PM
To: "pgsql-ad...@lists.postgresql.org" ,
"pgsql-general@lists.postgresql.org"
Subject: [External] How to revoke privileged from PostgreSQL's superuser
Hello,
I am a ne
Hello,
I am a newbie DBA.
I have a request for revoking the access to user's data from DBA-user.
I think the request is right because users should be the only ones can access
their data.
But DBA-user also need full access to the other data? It means that DBA-user
also needs to be a superuser.
21 matches
Mail list logo
