Re: [HACKERS] Spoofing as the postmaster
"Tom Lane" <[EMAIL PROTECTED]> writes: > "Marko Kreen" <[EMAIL PROTECTED]> writes: >> (FYI - Debian already puts unix socket to directory writable >> only to postgres user, so they dont have the problem. Maybe >> we should encourage distros to move away from /tmp?) > > No, we shouldn't, and if I had any authority over them I would make > Debian stop doing that. It amounts to a unilateral distro-specific > change in the protocol, and I think it makes things *less* secure, > because any clients who are expecting the socket to be in /tmp will be > easy pickings for a spoofer. Debian cannot hope to prevent that > scenario, because there are non-libpq-based client implementations. I don't understand this point of view. /tmp is there for users to play with. If you build Postgres as a user and run it from your home directory then you certainly can use /tmp or your home directory to communicate. But if Postgres is provided by the OS then it can't ignore the proper places dedicated to this purpose. Using /tmp for a shared system resource opens the door to serious problems such as the current issue. Also consider denial-of-service attacks by any user creating sockets in the way of Postgres. Bruce summarized the problem pretty well when he said that if Postgres is being run as a non-root user then one non-root user's "postgres" is as good as any other non-root user's "postgres". If you want to authenticate from to another user on the same machine you have to have some kind of credential which sets you apart. I actually think it's quite wrong of a shared resource to not be installed to run as root. It should cause problems like this in many places. Basically if you were never root then you can never really prove you're not an spoof. If you're content to take the "postgres" user as special then you could call getsockopt(SO_PEERCRED) to verify you're really connected to a process run by "postgres". But that isn't going to work if the postgres user could be named something else. In that case what is it you want to verify though? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] viewing source code
"Roberts, Jon" <[EMAIL PROTECTED]> writes: > Major Feature 3: Users will build their own functions to manipulate their > own data and share the output with their department. PostgreSQL security > currently does not secure the functions they write so the feature is not > fully met. Incidentally, are you really wedded to pl/pgsql functions? It seems like it would be far more powerful to allow them to build up a library of perl or python or whatever and put them in files in a blessed directory. Then you could have a few standard functions which they could use to call functions from those libraries. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Spoofing as the postmaster
Mark Mielke <[EMAIL PROTECTED]> writes: > Brendan Jurd wrote: >> It doesn't solve the spoofing attack problem, but isn't Gurjeet's idea >> a good one in any case? >> > What makes it good? It solves no problems. It prevents the server from > coming up when it otherwise might still be able to. The primary reason things work like that is that there are boatloads of machines that are marginally misconfigured. For instance, userland thinks there is IPv6 support when the kernel thinks not (or vice versa). If we made the postmaster abort every time it couldn't latch onto every address that the listen_addresses setting suggested it might be able to latch onto, what we'd mostly accomplish is to drive away a lot of potential users. Given that everyone agrees that this change wouldn't actually fix anything w.r.t. spoofing, I don't think there's grounds for making it. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Spoofing as the postmaster
Brendan Jurd wrote: It doesn't solve the spoofing attack problem, but isn't Gurjeet's idea a good one in any case? What makes it good? It solves no problems. It prevents the server from coming up when it otherwise might still be able to. If the postmaster can't bind on one of the specified interfaces, then at the least, haven't you got got a serious configuration error the sysadmin would want to know about? Having postmaster fail seems like a sensible response. I don't think it really matters what it does in the grand scheme of things, as it's not solving a real problem. "I can't start with the configuration you've given me, so I won't start at all" is fairly normal behaviour for a server process, no None of my servers work this way. If possible, I try to make my servers auto-recover at a later time while they are still up. It means an administrator does not need to login to a machine at the data center to solve the problem. "Self healing" is a term that is used to describe approaches such as this. Cheers, mark -- Mark Mielke <[EMAIL PROTECTED]>
Re: [HACKERS] Spoofing as the postmaster
Brendan Jurd wrote: > On Dec 23, 2007 1:25 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote: > > I have written documentation for this item: > > > > http://momjian.us/tmp/pgsql/server-shutdown.html#SERVER-SPOOFING > > > > Comments? > > I thought the content made sense, but the location didn't. I wouldn't > expect to find instructions on configuring Postgres for secure > operation under a section about how to shut the server down. > > I realise that in order for the exploit to occur, the server must be > shut down (or not yet started), but unless a user already knows about > the way the exploit works, how will they know to look for info about > it here? > > IMO by putting this guidance under "Shutting Down" you're going to > hurt the chances of anyone stumbling across it. I doubt you'd get > many users reading "Shutting Down" at all because in most cases, it's > an easy or obvious thing to do (initscripts provided by package and > pg_ctl are self-explanatory). Agreed. I moved it up to its own section: http://momjian.us/tmp/pgsql/preventing-server-spoofing.html I improved the wording slightly too. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Spoofing as the postmaster
On Dec 23, 2007 1:25 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote: > I have written documentation for this item: > > http://momjian.us/tmp/pgsql/server-shutdown.html#SERVER-SPOOFING > > Comments? I thought the content made sense, but the location didn't. I wouldn't expect to find instructions on configuring Postgres for secure operation under a section about how to shut the server down. I realise that in order for the exploit to occur, the server must be shut down (or not yet started), but unless a user already knows about the way the exploit works, how will they know to look for info about it here? IMO by putting this guidance under "Shutting Down" you're going to hurt the chances of anyone stumbling across it. I doubt you'd get many users reading "Shutting Down" at all because in most cases, it's an easy or obvious thing to do (initscripts provided by package and pg_ctl are self-explanatory). Regards, BJ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Spoofing as the postmaster
Bruce Momjian wrote: > I think at a minimum we need to add documentation that states if you > don't trust the local users on the postmaster server you should: > > o create unix domain socket files in a non-world-writable > directory > o require SSL server certificates for TCP connections I have written documentation for this item: http://momjian.us/tmp/pgsql/server-shutdown.html#SERVER-SPOOFING Comments? -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Spoofing as the postmaster
Brendan Jurd wrote: > On Dec 23, 2007 12:20 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote: > > Gurjeet Singh wrote: > > > On Dec 22, 2007 6:25 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote: > > > This way, if the attacker has control of even one interface (and > > > optionally the local socket) that the clients are expected to connect to, > > > the postmaster wouldn't start and the attacker won't have any traffic to > > > peek into. > > > > Yes, that would fix the problem I mentioned but at that point the > > attacker already has passwords so they can just connect themselves. > > Having the server fail if it can't get one interface makes the server > > less reliable. > > It doesn't solve the spoofing attack problem, but isn't Gurjeet's idea > a good one in any case? > > If the postmaster can't bind on one of the specified interfaces, then > at the least, haven't you got got a serious configuration error the > sysadmin would want to know about? Having postmaster fail seems like > a sensible response. > > "I can't start with the configuration you've given me, so I won't > start at all" is fairly normal behaviour for a server process, no? Yes, we have talked about this in the past and there were concerns that that the server might have some network problem that would prevent binding on all interfaces, particularly IPv6. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Spoofing as the postmaster
On Dec 23, 2007 12:20 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote: > Gurjeet Singh wrote: > > On Dec 22, 2007 6:25 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote: > > This way, if the attacker has control of even one interface (and > > optionally the local socket) that the clients are expected to connect to, > > the postmaster wouldn't start and the attacker won't have any traffic to > > peek into. > > Yes, that would fix the problem I mentioned but at that point the > attacker already has passwords so they can just connect themselves. > Having the server fail if it can't get one interface makes the server > less reliable. It doesn't solve the spoofing attack problem, but isn't Gurjeet's idea a good one in any case? If the postmaster can't bind on one of the specified interfaces, then at the least, haven't you got got a serious configuration error the sysadmin would want to know about? Having postmaster fail seems like a sensible response. "I can't start with the configuration you've given me, so I won't start at all" is fairly normal behaviour for a server process, no? Regards, BJ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Spoofing as the postmaster
Gurjeet Singh wrote: > On Dec 22, 2007 6:25 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote: > > > > > It is possible for the attacker to use one of the interfaces (tcp or > > unix domain) and wait for the postmaster to start. The postmaster will > > fail to start on the interface in use but will start on the other > > interface and the attacker could route queries to the active postmaster > > interface. > > > > > I am not very conversant with networking, but I see a possibly simple > solution. Why not refuse to start the postmaster if we are unable to bind > with any of the interfaces (all that are specified in the conf file). > > This way, if the attacker has control of even one interface (and > optionally the local socket) that the clients are expected to connect to, > the postmaster wouldn't start and the attacker won't have any traffic to > peek into. Yes, that would fix the problem I mentioned but at that point the attacker already has passwords so they can just connect themselves. Having the server fail if it can't get one interface makes the server less reliable. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Spoofing as the postmaster
On Dec 22, 2007 6:25 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote: > > It is possible for the attacker to use one of the interfaces (tcp or > unix domain) and wait for the postmaster to start. The postmaster will > fail to start on the interface in use but will start on the other > interface and the attacker could route queries to the active postmaster > interface. > > I am not very conversant with networking, but I see a possibly simple solution. Why not refuse to start the postmaster if we are unable to bind with any of the interfaces (all that are specified in the conf file). This way, if the attacker has control of even one interface (and optionally the local socket) that the clients are expected to connect to, the postmaster wouldn't start and the attacker won't have any traffic to peek into. Best regards, -- [EMAIL PROTECTED] [EMAIL PROTECTED] gmail | hotmail | indiatimes | yahoo }.com EnterpriseDB http://www.enterprisedb.com 17° 29' 34.37"N, 78° 30' 59.76"E - Hyderabad 18° 32' 57.25"N, 73° 56' 25.42"E - Pune 37° 47' 19.72"N, 122° 24' 1.69" W - San Francisco * http://gurjeet.frihost.net Mail sent from my BlackLaptop device
Re: [HACKERS] viewing source code
* Roberts, Jon ([EMAIL PROTECTED]) wrote: > Major Feature 3: Users will build their own functions to manipulate their > own data and share the output with their department. PostgreSQL security > currently does not secure the functions they write so the feature is not > fully met. Alright, this isn't *completely* thought out, and I know it's not a perfect solution, but to get something going in a released version of PG... Store the function definitions in a table, just per usual, and use PG permissions and whatnot to handle keeping it safe. Write a simple 'helper' function which wouldn't have anything sensetive in it which will take the function name as an argument. Then, in a transaction, it could create the appropriate function, run it, and then drop it. Probably not practical in an on-line/heavy-usage transactional system due to the added overhead, but doing it for a data warehouse type solution where the functions do alot of heavy lifting but aren't run very often might be alright. Yes, it would also get ugly if you had alot of functions building on other functions and whatnot. It also wouldn't work too well if the person running the function isn't supposed to be able to see it, but that doesn't sound like the case here. While I've never really had a reason to secure my functions, I'm not against providing a way to do it in PG. I'm not sure if what you've outlined is the best approach or it might be better to come up with a generic, system-table-wide, way to limit who can see what (for example, prevent users from being able to see table definitions in schemas they don't have usage rights on). Enjoy, Stephen signature.asc Description: Digital signature
[HACKERS] viewing source code
Tom Lane indicated this thread should be moved here. Instead of asking for what I consider the solution, let me propose a real business case and you guys tell me how best to handle it. I am building an Enterprise Data Warehouse with PostgreSQL. BTW, I love this database. I will have data from all over the company housed in it and a variety of business users from all over the company as well. Users Communities Call Center Finance Sales IT Marketing HR Security Major Feature 1: These users will be using common dimensions and fact tables that are unique to each department. PostgreSQL security will handle this just fine. Major Feature 2: Users will be able to load their own data into the data warehouse and secure this to their department. PostgreSQL security will handle this just fine. Major Feature 3: Users will build their own functions to manipulate their own data and share the output with their department. PostgreSQL security currently does not secure the functions they write so the feature is not fully met. The user community is not highly technical and they are not looking for an obfuscation solution. They are looking for simple security to their code they write in pl/pgsql that is similar if not the same as the security for protecting their data. How best can I achieve Major Feature 3? Examples of what would be in the functions that need to be secured: 1. HR could have pay and performance calculations that they don't want shared with other departments. 2. Finance could have earnings calculations they don't want to share with marketing. 3. Security could have functions to identify network abusers. 4. Finance could have fraud and abuse calculations they don't want to share with the call center. Building a database per department isn't feasible. It would require a vast amount of data replication and duplication. We want an Enterprise solution. One solution already proposed is to create a view in place of the pg_proc table. The source code column would be protected in a similar fashion to pg_stat_activity.current_query. This seems like a great solution to me and it would meet our Major Feature 3. Jon ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Spoofing as the postmaster
"Marko Kreen" <[EMAIL PROTECTED]> writes: > (FYI - Debian already puts unix socket to directory writable > only to postgres user, so they dont have the problem. Maybe > we should encourage distros to move away from /tmp?) No, we shouldn't, and if I had any authority over them I would make Debian stop doing that. It amounts to a unilateral distro-specific change in the protocol, and I think it makes things *less* secure, because any clients who are expecting the socket to be in /tmp will be easy pickings for a spoofer. Debian cannot hope to prevent that scenario, because there are non-libpq-based client implementations. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Spoofing as the postmaster
"Mike Rylander" <[EMAIL PROTECTED]> writes:
> On Dec 22, 2007 1:04 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Hmm ... we've always thought of SSL as being primarily comm security
>> and thus useless on a Unix socket, but the mutual authentication aspect
>> could come in handy as an answer for this type of threat. Anyone want
>> to try this and see if it really works or not?
>>
>> Does OpenSSL have a mode where it only does mutual auth and not
>> encryption?
> [EMAIL PROTECTED]:~$ openssl ciphers -v 'NULL'
Cool. I took a quick look through the code, and I think that a smoke
test could be made just by diking out these lines in
src/interfaces/libpq/fe-connect.c:
if (IS_AF_UNIX(conn->raddr.addr.ss_family))
{
/* Don't bother requesting SSL over a Unix socket */
conn->allow_ssl_try = false;
}
Actual support would require rather more effort --- for instance,
I doubt that the default behavior should be to try to do SSL over a
socket, so "sslmode" would need some extension, and we'd want to extend
the pg_hba.conf keywords --- but I think this would be enough to allow
verifying whether it will work.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Spoofing as the postmaster
On 12/22/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote: > Bruce Momjian wrote: > > The fundamental problem is that because we don't require root, any user's > > postmaster or pretend postmaster is as legitimate as anyone else's. SSL > > certificates add legitimacy checks for TCP, but not for unix domain > > sockets. > > Wouldn't SSL work over Unix-domain sockets as well? The API only deals with > file descriptors. For Unix sockets it should be enough to just check server process uid, no? (FYI - Debian already puts unix socket to directory writable only to postgres user, so they dont have the problem. Maybe we should encourage distros to move away from /tmp?) -- marko ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Spoofing as the postmaster
On Dec 22, 2007 1:04 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > Wouldn't SSL work over Unix-domain sockets as well? The API only deals with > > file descriptors. > > Hmm ... we've always thought of SSL as being primarily comm security > and thus useless on a Unix socket, but the mutual authentication aspect > could come in handy as an answer for this type of threat. Anyone want > to try this and see if it really works or not? > > Does OpenSSL have a mode where it only does mutual auth and not > encryption? The encryption would be wasted cycles in this scenario, > so being able to turn it off would be nice. > [EMAIL PROTECTED]:~$ openssl ciphers -v 'NULL' NULL-SHASSLv3 Kx=RSA Au=RSA Enc=None Mac=SHA1 NULL-MD5SSLv3 Kx=RSA Au=RSA Enc=None Mac=MD5 I see no way to turn off the message digest, but maybe that's just an added benefit. --miker ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Spoofing as the postmaster
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Wouldn't SSL work over Unix-domain sockets as well? The API only deals with > file descriptors. Hmm ... we've always thought of SSL as being primarily comm security and thus useless on a Unix socket, but the mutual authentication aspect could come in handy as an answer for this type of threat. Anyone want to try this and see if it really works or not? Does OpenSSL have a mode where it only does mutual auth and not encryption? The encryption would be wasted cycles in this scenario, so being able to turn it off would be nice. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Spoofing as the postmaster
Andrew Dunstan wrote: > > > Peter Eisentraut wrote: >> Bruce Momjian wrote: >> >>> The fundamental problem is that because we don't require root, any >>> user's >>> postmaster or pretend postmaster is as legitimate as anyone else's. SSL >>> certificates add legitimacy checks for TCP, but not for unix domain >>> sockets. >>> >> >> Wouldn't SSL work over Unix-domain sockets as well? The API only >> deals with file descriptors. >> >> > > But we don't check the SSL cert's credentials in the client, AFAIK. That > means that postmaster spoofer could just as easily spoof SSL. > Communications between the client and the endpoint will be protected, > but there is no protection from a man in the middle attack, which is > what this is. We do if you put the CA cert on the client. //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Spoofing as the postmaster
Andrew Dunstan wrote: > But we don't check the SSL cert's credentials in the client, AFAIK. We do if you configure it so. But I must admit that this fact is not well advertised. It is documented, but you have to look carefully. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Spoofing as the postmaster
Peter Eisentraut wrote: Bruce Momjian wrote: The fundamental problem is that because we don't require root, any user's postmaster or pretend postmaster is as legitimate as anyone else's. SSL certificates add legitimacy checks for TCP, but not for unix domain sockets. Wouldn't SSL work over Unix-domain sockets as well? The API only deals with file descriptors. But we don't check the SSL cert's credentials in the client, AFAIK. That means that postmaster spoofer could just as easily spoof SSL. Communications between the client and the endpoint will be protected, but there is no protection from a man in the middle attack, which is what this is. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Spoofing as the postmaster
Bruce Momjian wrote: > The fundamental problem is that because we don't require root, any user's > postmaster or pretend postmaster is as legitimate as anyone else's. SSL > certificates add legitimacy checks for TCP, but not for unix domain > sockets. Wouldn't SSL work over Unix-domain sockets as well? The API only deals with file descriptors. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Spoofing as the postmaster
On Sat, 22 Dec 2007 09:25:05 -0500 (EST) Bruce Momjian <[EMAIL PROTECTED]> wrote: > I think at a minimum we need to add documentation that states if you > don't trust the local users on the postmaster server you should: > > o create unix domain socket files in a non-world-writable > directory > o require SSL server certificates for TCP connections > > Ideas? It's generally a bad idea to put your database on a public server anyway but if you do you should definitely disable unix domain sockets and connect over TCP to localhost. That has been our rule for years. It's certainly a corner case. I would think that warnings, perhaps in the config file itself, would be sufficient. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] timetz range check issue
>Tom Lane wrote: >>range-checks are present only where needed for the backend to defend itself Survival is very important, but so is maintaining data integrity. IMHO, data validation should be as consistent as possible. If the backend refuses data on one hand but allows it on the other, confusion sets in. I realize that binary input can't always be 100% validated, but a best effort is good form. It looks like most recv funcs already have checks, where a check is somewhat meaningful. andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Spoofing as the postmaster
A few months ago a security concern was sent to core. We have discussed it but see little we can do to address it in the code so I am posting to hackers in case there is something we didn't think of or if documentation additions are necessary. Most users understand that if they are connecting to the postmaster over an insecure network that it is possible for a middle-man to intercept passwords, queries, and results. SSL certificates are designed to avoid this problem. The new attack vector reported involves a local user on the same machine as the postmaster. When the postmaster is running it has bound port 5432 and created the unix-domain socket file in /tmp. The new attack involves cases where the postmaster is stopped. The attacker can bind to TCP port 5432 or create a socket file in /tmp and get passwords and queries. PGDATA is secure so results cannot be returned while the postmaster is down. They can also prevent the real server from starting. It is possible for the attacker to use one of the interfaces (tcp or unix domain) and wait for the postmaster to start. The postmaster will fail to start on the interface in use but will start on the other interface and the attacker could route queries to the active postmaster interface. So, what solutions exist? We could require the use of port numbers less than 1024 which typically require root and then become a non-root user, but that requires root to start the server. We could put the unix domain socket file in a secure directory (but where?) but the client has to know that location. An interesting idea would be for the unix domain client to check that the ownership of the socket file is the same as PGDATA, but clients typically don't know PGDATA, nor do they know who should be running the postmaster. I suppose we could create a poor-man's SSL for unix domain sockets that just checks the ownership of the socket file, but users can already do that by specifying the socket file in a directory that only has write permission for the postmaster user. Could we create some kind of lock mode that keeps these interfaces locked when the postmaster is down? Conclusion -- The fundamental problem is that because we don't require root, any user's postmaster or pretend postmaster is as legitimate as anyone else's. SSL certificates add legitimacy checks for TCP, but not for unix domain sockets. This is not a Postgres-specific problem. It is probably shared by any server that doesn't need root permissions, but our handling of passwords makes it a larger problem. I think at a minimum we need to add documentation that states if you don't trust the local users on the postmaster server you should: o create unix domain socket files in a non-world-writable directory o require SSL server certificates for TCP connections Ideas? Remember, as long as your postmaster is running you are safe. It is only postmaster downtime that has this risk. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] binary decode
On Sat, Dec 22, 2007 at 02:07:28AM -0500, Francisco wrote: > I'm working on a decoder to take a raw main/base file and given table format > parameters to pull out relevant data. > > My question is whether anyone has developed such a tool. Something that > takes the raw file and table format as input and creates an ascii dump > (similar to pgdump). Yes, I wrote a program called pgfsck years ago which did this. Not for all data types, but most of the common ones. I'm in the process up upgrading it work with the latest versions. Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ > Those who make peaceful revolution impossible will make violent revolution > inevitable. > -- John F Kennedy signature.asc Description: Digital signature
Re: [HACKERS] Sorting Improvements for 8.4
"Brian Hurt" <[EMAIL PROTECTED]> writes: > 3) It's possible to perform the sort lazily. You have the initial O(N) pass > over the list, but then each block is only O(log N) cost. If it's likely that > only the first part of the result is needed, then much of the work can be > avoided. Now that's a *fascinating* idea. I'm having trouble coming up with a really killer use case for it since the bounded heap sort takes care of many cases where it would seem to apply. But it seems rally promising. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Negative LIMIT and OFFSET?
This has been saved for the 8.4 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Andrew Sullivan wrote: > On Sun, Dec 16, 2007 at 12:31:11PM -0500, Tom Lane wrote: > > > > Well, I wouldn't advocate making it in a minor release, but it's not > > clear how that translates into saying it can't go into 8.3. > > Just because we're well past feature freeze, in beta. I realise this seems > like a corner case, but the whole point of having betas where functionality > is more or less frozen is to reduce the liklihood that someone's testing on > (say) beta 2 is not all completely invalidated on beta 4. > > A > > ---(end of broadcast)--- > TIP 7: You can help support the PostgreSQL project by donating at > > http://www.postgresql.org/about/donate -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
