[HACKERS] Real Life Data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey, Does someone know of a huge load of real life LIKE data, maybe in CSV format that I can download somewhere, to demonstrate certain design techniques. Enough data to really see an effect of the difference in tables with/without indexes and so on. This would really be appreciated. ; Q Beukes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRAw96LEDZDQ16UzTAQJrAAgAoCfD0gyAk6GMKgtpiOO5l3RacceEp090 lAsxNIL6ofZxS0cn7D5yzHZW4Qrk7tdWcWjoBF27mEZ76lOSXODJbjq+QSVMDeTB /d/LHHQ31tmEcG46BmH1jfOq0VqBvLxAdYEGt1GO2ZeElGDuYXPv9RDH1GhpwLBb 74QyN3z+IVQYdp4FFkRjbfhOY7qKKdCMPu+z6ok6hM5b6moDF4LkBRLRddElOgLF 71Co98dTpIipGxnAQy28HrvC7tnROqJrkIHCGc7RZG0XUairjBWlFV+CKbtFJEie 45Fdnp6y8xazMPEoKHY33OQ1/hDq20iooNt8jqBWqA9IO6hNQI+d4A== =a7BC -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Feature Request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey, This might not be much, but can there maybe be a future feature for having a shortcut to set search_path='schema-name'; similiar to \c dbname ?? Thx Quintin Beukes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQ/nBC7EDZDQ16UzTAQJsPQf+JHKB/oYppYH1vSD/ar2YQEiTgs2mHsbc FfjftZTykf+P7jrA78ZrttlQEnW09A1Ul3qvNmAGDNs7n2XGHZH7q7539RMjh1h6 Lb5PUwbVtFehUbcMNkocIQsJx/rs6kKfB2sau5ZkrOK+NIyHiTYU3hXpSj2v5Zp5 nAcf8arNlL0zKPhoZCTg4eP0Bx8OvfJeMSAnpnuc17bnMqm8EWAenjr86LFb/L1L mW7+x5vo/ZIoj8FZVKx3Iiy5Zu2K3ylZ8gqGbL9H1i/xTmWRhypQMwMxZ3suiAMT MLlnC1iYRj2x+aTA0RbYdVJqcS/hjFwbi8T0JI/GOtHxPgyDMJwbEQ== =ma34 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] pg_hba.conf alternative
how? is there some kernel patch to completely to enable you to deny access to root? Tino Wildenhain pointed out SELinux has a feature like that. Rick Gigger wrote: But why do they need access to the files in the file system? Why not put them on the local box but don't give them permissions to edit the pg_hba file? They should still be able to connect. On Feb 9, 2006, at 5:56 PM, Q Beukes wrote: I did consider that, but the software we use (which again uses postgresql) atm only supports local connection to the database. I am the database admin, the other admins just manage stuff like user accounts, checking logs, etc... Unfortunately there is no other way to set it up, and like I mentioned government security is not required. I did however statically code the pg_hba.conf file into pg binaries. The only way I found to access the db now would be to replace the binary and possibly sniffing traffic. But we're not worried about that. They not really criminally minded people. thx for everyones help anyway ; korry wrote: Why would you not simply set this up on a seperate machine to which only the trusted admins had access? Most data centers I am familiar with use single purpose machines anyway. If someone is trusted as root on your box they can screw you no matter what you do. Pretending otherwise is just folly. Agreed - that would be a much better (easier and more secure) solution where practical. -- Korry ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] pg_hba.conf alternative
I did consider that, but the software we use (which again uses postgresql) atm only supports local connection to the database. I am the database admin, the other admins just manage stuff like user accounts, checking logs, etc... Unfortunately there is no other way to set it up, and like I mentioned government security is not required. I did however statically code the pg_hba.conf file into pg binaries. The only way I found to access the db now would be to replace the binary and possibly sniffing traffic. But we're not worried about that. They not really criminally minded people. thx for everyones help anyway ; korry wrote: Why would you not simply set this up on a seperate machine to which only the trusted admins had access? Most data centers I am familiar with use single purpose machines anyway. If someone is trusted as root on your box they can screw you no matter what you do. Pretending otherwise is just folly. Agreed - that would be a much better (easier and more secure) solution where practical. -- Korry ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_hba.conf alternative
To give it to you straight... its just to ease the minds of management. Someone pointed out to them how easy it really is to access the data, and this kind of started to make them feel uncomfortable. They know the admins are very computer literate and that any protection can be broken by them. But it's just like information locked inside a cabinet, it can be accessed by breaking in right? But employees wont do it, because it's just not ethical to break into your employers private stash. But if it was lying on a paper on a desk somewhere, even the most honest employee might peek onto it for interest sake. And this type of information can stir quite a bit, trust me. That is all I was wondering about, if there was a way to just lock it inside a cabinet with a tiny bit more security. After that you can always take measures to make sure they aren't installing malicious software, or taking information home. You can install software like Tripwire to make sure the binaries are kept fine, remove gcc and so forth. Tino Wildenhain wrote: Q Beukes schrieb: Well, I am not looking for 100% security. I know that full access if full access, and that even if you were to encrypt the system through Postgre the determined person WILL always be able to get it out if they have system level access. All I wanted to do was to prevent the basic SQL/Linux literate user from accessing the databases. At the moment it is very easy for them to access the data. I trust that they wont go as far as overwriting the system with custom compiled version, or copying the data and so forth. It just that we would feel much better if we knew the data wasn't as open as it is now, with a simple pg restart it is all open? Can this only be done by maybe modifying the source to make pg_hba fields statically compiled into the executable? Instead, you might want to read about SELinux. You can protect files even to root (unless they reboot ;) but really you should have only trusted people have admin accounts. How comes you have somebody untrusted as admin? Regards Tino ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] {I} One Information required...
Hey, Simply create a new non adminstrator user, say postgres with a password. Give this user write permissions to the empty data directory. Then login as this user and run initdb like did before. You are going to have to register the postgres service under this user too. You can do this by running pg_ctl like this: pg_ctl.exe register -N PostgreSQL -U [user] -P [user password] After this you can run: net start PostgreSQL to start postgres, or you can use the windows tool to start/stop services. If you dont want to register the service you will have to login to this user everytime in order to start postgresql. Services are a handy Windows feature. There is also a tool in windows with which you can run commands under other users, similiar to su in linux, but I can't remember the name. Google for it if you wish to take this route. any questions feel free to mail me ; regards Quintin Beukes Premnath, KN wrote: Hi all, When I try to run initdb id get the messing creating template1 database in c:/postgres/data/base/1 ... Execution of PostgreS QL by a user with administrative permissions is not permitted. The server must be started under an unprivileged user ID to prevent possible system security compromises. See the documentation for more information on how to properly start the server. OS I am using : Windows 2000 Professional I understand this message. Actually I created a new user postgres with password as different than postgres, also gave permission to the c:\postgres (installation folder) with postgres user permission. When I specify runas /noprofile /user:postgres cmd and then when I specify initdb I am getting the above error message, this is with Postgres 8.1, in the past with postgres 7.x I am not facing this problem. One surprising observation what I see is that = when I run initdb the cmd shell is showing The files belonging to this database system will be owned by user pk00. This user must also own the server process. where pk00 is the machine what I logged in. *Question:* *How to configure initdb to use postgres instead of pk00 user. Anyone kindly help in this regard.* Thank You. With warm regards, */Premnath.k.n/* Siemens Communication Software, 2nd floor, Shankara Narayana Building-1, 25/1 Mahatma Gandhi Road, Bangalore - 560 001, India. /Phone: Off : 91-80-2506 2400, 2559 4067 - 73 / /Extn : 6369/ / Fax : 91-80-2506 2406/ / Resi : 91-80-28436106/ / Mobile: 91-98445 19798/ /Email: [EMAIL PROTECTED]/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] pg_hba.conf alternative
Hello, Is there not some other alternative to pg_hba.conf? I have the problem where the system administrators at our company obviously have access to the whole filesystem, and our database records needs to be hidden even from them. With pg_hba.conf that is not possible, as they just change all the conf lines to trust auth and viola they have access to the database without passwords. Is there a more secure alternative to this? The perfect scenario being to deny everyone include root access to a database without a password. regards, Quintin Beukes ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] pg_hba.conf alternative
Well, I am not looking for 100% security. I know that full access if full access, and that even if you were to encrypt the system through Postgre the determined person WILL always be able to get it out if they have system level access. All I wanted to do was to prevent the basic SQL/Linux literate user from accessing the databases. At the moment it is very easy for them to access the data. I trust that they wont go as far as overwriting the system with custom compiled version, or copying the data and so forth. It just that we would feel much better if we knew the data wasn't as open as it is now, with a simple pg restart it is all open? Can this only be done by maybe modifying the source to make pg_hba fields statically compiled into the executable? Martijn van Oosterhout wrote: On Wed, Feb 08, 2006 at 02:34:29PM +0200, Q Beukes wrote: Is there not some other alternative to pg_hba.conf? I have the problem where the system administrators at our company obviously have access to the whole filesystem, and our database records needs to be hidden even from them. With pg_hba.conf that is not possible, as they just change all the conf lines to trust auth and viola they have access to the database without passwords. Or they just copy the whole database to another machine and access it that way. Or copy your backups. Or hack the application accessing the data (the application has the password in it, right?). If can stop them doing those things you can stop them altering pg_hba.conf too so your problem is solved. Is there a more secure alternative to this? The perfect scenario being to deny everyone include root access to a database without a password. Well, you could change the source to remove struct auth, but then they'd just compile their own version and overwrite the system one. Yes, we're looking for alternatives for pg_hba.conf, but what you want is to dam a river with sheets of paper. Have a nice day, ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
