Hi
Is it possible to have an update query that will specify actions,
timestamp, user who’s making the update inside the database. Can this be
done without any script but just in the transaction block
Example:
dbtest=# UPDATE table test set t4 = 9 where t1 = 001 then specify
user_name,
What do you want to have happen to the timestamp/user?
You can obviously do:
update test set t4 = 9, user = someuser, timestamp = sometimestamp
where t1 = 001;
I'm assuming you're trying to store the user and timestamp somewhere
else, though?
Robin
On Wed, 2012-03-14 at 12:44 +0200,
thanks, the issue we have is that we have many Linux users having root
access into the system. So they're able to access the DB by just going in as
su - superusername. If this user is able to make any updates inside the
database it might create problems. Auditors wants PostgreSQL to tell who
Hi, anyone with an idea based on my latest comments below? Thanks
-Original Message-
From: Khangelani Gama [mailto:kg...@argility.com]
Sent: Wednesday, March 14, 2012 1:25 PM
To: 'Robin Iddon'; 'pgsql-admin@postgresql.org'
Subject: RE: [ADMIN] Update actions (with user name) inside
You lose if you have provided people you do not trust with root access
they can be whoever they want to be and there is nothing you can do
about it. In my belief there is absolutely no way of making the system
safe with untrusted root users. Don't waste your time trying.
Any attempt to create
On Mar 14, 2012, at 6:39 AM, Khangelani Gama wrote:
...the issue we have is that we have many Linux users having root
access into the system... Auditors wants PostgreSQL to tell who
updated what inside the database...
Well, this is an obvious contradiction. You have an inherently
Khangelani Gama kg...@argility.com wrote:
the issue we have is that we have many Linux users having root
access into the system.
Which gives them rights to impersonate any other user on the system
and to erase any audit trail written on that system.
Auditors wants PostgreSQL to tell who
In Linux you can setup and use the sudo option. For those whom you don't
wish to have root access, simply make them sudousers, then change the root
password. This will force those users to simply type sudo (w/o quotes) at
the beginning of each command they want to run (i.e. sudo psql db_name
On Mar 14, 2012, at 9:01 AM, David Ondrejik wrote:
In Linux you can setup and use the sudo option. For those whom you don't
wish to have root access, simply make them sudousers, then change the root
password. This will force those users to simply type sudo (w/o quotes) at
the beginning of
*Sure, you mean like this command:
sudo su root
???*
Luckily...that option will fail using sudo...and it will be logged that it
was attempted. I see where you are going with this Scott and there is an
option that will work to give you a root shell, but I don't want to
advertise that. That
On Mar 14, 2012, at 9:28 AM, David Ondrejik wrote:
So there is some trail to track back to the original user.
Yes, but once he has root shell, the trail ends there, and impersonation of
anyone is once again trivial. Also, sudo su root, does work on some unices, and
the option you don't want
Scott,
You are correct and I agree with you. The sudo option would work best with
individuals who do not have much Linux SA experience to know or figure
out these options.
I agree with the original premises posted by several that limiting the
number of people with root access is the best option.
Scott Ribe wrote:
On Mar 14, 2012, at 9:01 AM, David Ondrejik wrote:
In Linux you can setup and use the sudo option. For those whom you don't wish to have root
access, simply make them sudousers, then change the root password. This will force those users to simply type
sudo (w/o quotes) at
Constrained sudo is no substitute for proper security. If I was in
charge of a database where personal details or credit card or financial
information could be compromised I would not rely on constrained sudo.
The reason is that no matter how smart you think you are, some smarty
pants always
On Wed, Mar 14, 2012 at 5:24 AM, Khangelani Gama kg...@argility.com wrote:
thanks, the issue we have is that we have many Linux users having root
access into the system.
That's the problem right there. Setup a separate db server that only
your DBA can log into the shell on. Then make it so
On Wed, 14 Mar 2012 13:24:36 +0200, Khangelani Gama wrote:
thanks, the issue we have is that we have many Linux users having root
access into the system. So they're able to access the DB by just going
in as su - superusername. If this user is able to make any updates
inside the database it
Thanks to everyone for the ideas, the information you provided me with
was much needed. it's much appreciated.
C O N F I D E N T I A L I T Y N O T I C E
The contents of and attachments to this e-mail are intended for the
addressee only, and may contain the confidential information of
17 matches
Mail list logo
