Re: [HACKERS] Re: [COMMITTERS] pgsql: Add support for matching wildcard server certificates to the new
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Tom Lane wrote: * This seems to be still mostly NetBSD code, so I think you need to do more than just credit them in an aside. Should we repeat the full NetBSD copyright notice for this one function? Do you mean the * Copyright (c) 1989, 1993, 1994 * The Regents of the University of California. All rights reserved. * * This code is derived from software contributed to Berkeley by * Guido van Rossum. part, or the whole licence? Since the licence is the same as ours, doing that seems like overkill. Well, it does say * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. Right, maybe we'd better do that even if it's identical to our own. Better credit too much than not enough. I'll put the whole thing in - will move the function to the bottom of the file as well to clearly isolate which parts it's referring to. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Add support for matching wildcard server certificates to the new
Peter Eisentraut wrote: On Friday 28 November 2008 17:13:54 Magnus Hagander wrote: Matching *only* as the first character will make it impossible to make certificates for www*.domain.com, which is AFAIK fairly popular - and one of the examples you'll find on CA sites. But it would be fairly easy to add this restriction if people feel that's a better way. Are there actual technical or administrative or security arguments for or against this? For example, what are the criteria one has to fulfill in order to get such a certificate? Or is there a defensive certification security line of reasoning? Now certificate issuing is a real business, so we need to play in that context as well, but I would like to dig a little deeper why things should be done in a certain way. I am quite confortable, for example, with * matching subdomains, because if I own example.com, then I can create any level of subdomain I want, without making a real difference to user/client program. But then I don't really get the point of having * inside of words -- would www*.domain.com also match dots then? Hmm. I can't seem to find that reference anymore. The only one of my www* references I can find ATM is GoDaddy which just has it as an exapmle of what *.domain.com would match :S Perhaps the best method would actually be to match only *. at the beginning of the CN for now, and see if people complain? I would much like someone who knows more about what would be reasonable to speak up here, but it seems we don't have anybody here who knows... //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1197)
KaiGai Kohei wrote: Bruce Momjian wrote: KaiGai Kohei wrote: What I am saying is for the default compile, SQL-level ACLs should be possible because, since the ACL field has optional storage, there is no downside to have it be available by default. I think it is a possible and desirable desicion from the viewpoint of security folks. However, I think we have a few issues, and it makes unclear whether we can make an agreement in the community. The one is a cost of security hooks. They consume a bit more CPU steps when a security mechanism is enabled. The other is prevention to override a few hooks (ExecutorRun_hook and planner_hook), because they assume standard implementations to be executed. Which is more desirable option in the default? Well, my assumption is that if a table doesn't have SQL-level row permissions then there is no overhead becaues there are no permissions to check. When the binary is built with the SQL-level row permissions and scanned table does not activated it, all it does is checking a flag variable at Relation-rd_options. I guess it will be acceptable cost. In this case, DBA disables row-level permission on the table, so no additional security field is required. For example, I might want to put SQL-level row permissions on an audit table, but none of my other tables, and in that case I assume there is only a performance impact on queries that use the audit table. It is not a zero, but tiny as far as we can ignore it in my opinion. Yes. It is good to have SQL-level row security available by default in every binary, even if it requires a few checks in C. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Add support for matching wildcard server certificates to the new
Perhaps the best method would actually be to match only *. at the beginning of the CN for now, and see if people complain? I would much like someone who knows more about what would be reasonable to speak up here, but it seems we don't have anybody here who knows... I would encourage you to adopt a solution where * matches only a single pathname component. This seems to be the intention of both RFC2818 and RFC2595. It is also the behavior of IE7; FF2 seems to deviate from the spec. http://www.hanselman.com/blog/SomeTroubleWithWildcardSSLCertificatesFireFoxAndRFC2818.aspx There are several other advantages of this approach that seem worth mentioning: 1. If you make it match a single pathname component now, and later decide that you were wrong and change your mind, it is guaranteed not to break any working installations. The reverse is not true. 2. I can't see any possible way that matching a single component could create security holes that would be eliminated by matching multiple components, but I'm more skeptical about the other direction. What about the old DNS hack where you create a DNS record for example.com.sample.com and hijack connections intended for example.com made by people whose default DNS suffix is sample.com? There may be reason to believe this isn't a problem, but matching less seems like it can't possibly be a bad thing. 3. It would be truly bizarre if www*.example.com matched www17.some.stuff.in.the.middle.example.com. (That having been said, I wouldn't worry about wildcards intended to match part of a component too much. I suspect that it's an extremely rare case, and we can always add support later if there is demand for it. Not worrying about this now will help keep the code simple and free of bugs, always good in a security-critical context.) ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Statement-level triggers and inheritance
On Friday 28 November 2008 16:59:19 Tom Lane wrote: Greg Sabino Mullane [EMAIL PROTECTED] writes: Looks like inheritance causes a statement-level trigger to fire on the last evaluated table in the inheritance chain. Is this the desired behavior? Hm, I think whoever wrote the statement-level trigger code completely forgot to consider the possibility of multiple target relations. It's not even consistent between BEFORE and AFTER triggers for this case. My feeling is that it ought to fire such triggers on *each* target. This would amount to statement level triggers firing multiple times per statement wouldn't it? That behavior might be rather surprising for folks. I guess the alternative is to have it fire only on the parent in an inheritance stack. I'm not sure that's much more defensible, but maybe it's more practical? -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Statement-level triggers and inheritance
Robert Treat [EMAIL PROTECTED] writes: On Friday 28 November 2008 16:59:19 Tom Lane wrote: My feeling is that it ought to fire such triggers on *each* target. This would amount to statement level triggers firing multiple times per statement wouldn't it? No, because they'd be different triggers. A trigger on a parent table has got nothing to do with triggers on children. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: Hash Join-Filter Pruning using Bloom Filters
Jonah H. Harris [EMAIL PROTECTED] writes: I have a new patch which does not create a bloom filter unless it sees that the hash join is going to batch. I'll send it along later tonight. So ... where's the updated patch? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #4553: HOLD cursors not materializing results fully
Andrew Gierth [EMAIL PROTECTED] writes: The materialization logic for holdable cursors isn't detoasting data prior to storage in the portal's tuplestore, which leads to problems like this: Hmm ... I think we'd seen this reported once before in the context of dropping the cursor's source table, which didn't seem tremendously pressing to fix. However, an example involving just VACUUM obviously raises the priority a bit. I concur that the only reasonable fix is to detoast any out-of-line datums (fortunately we don't have to decompress them too) while pushing the data into the hold store. It doesn't seem too difficult to make this happen in tstoreReceiver.c, but there's an API issue: we use tstoreReceiver.c also for a number of cases with regular non-holdable Portals, and we surely don't want to incur the detoasting overhead in those cases. So it seems we need one more parameter for creation of a tuplestore DestReceiver, to tell it whether to detoast or not. ISTM this puts the final nail in the coffin of the present API of CreateDestReceiver: the majority of its callers are going to be working around its inadequate ability to pass receiver-type-specific arguments. There are a number of possible solutions: abandon CreateDestReceiver altogether, allow it to pass through a void * parameter, etc. What I'm kind of inclined to do is just to remove its Portal argument and require callers that need to pass information to call a receiver-type-specific set parameters function after the basic CreateDestReceiver step. Or we could leave CreateDestReceiver alone and make tuplestore DestReceiver creation examine the state of the portal to decide what to do; but that seems pretty ugly/fragile. It might be the way to do it in the back branches, though, to avoid an API change there. (I have no idea if there's any third-party code calling CreateDestReceiver...) Comments, better ideas? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
