Re: [HACKERS] 8.4 release planning
David Fetter writes: > On Mon, Jan 26, 2009 at 03:12:02PM -0500, Tom Lane wrote: >> I don't think this is correct. > I do. > People literally grab my shoulder and ask when we'll have it. Do these people understand the difference between HS and a complete replication solution? Are they still as excited after you explain the difference? 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] 8.4 release planning
On Tue, 2009-01-27 at 11:36 -0500, Tom Lane wrote: > David Fetter writes: > > On Mon, Jan 26, 2009 at 03:12:02PM -0500, Tom Lane wrote: > >> I don't think this is correct. > > > I do. > > > People literally grab my shoulder and ask when we'll have it. > > Do these people understand the difference between HS and a complete > replication solution? Are they still as excited after you explain > the difference? No. Because everyone I see rambling about it don't realize there is a difference. Joshua D. Drake > > regards, tom lane > -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- 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] 8.4 release planning
On Tue, 2009-01-27 at 11:26 -0500, Tom Lane wrote: > Yeah, people like certification, but they also like products that work. > Did you stop reading before getting to my non-security-based complaints? Yes, I'm sorry, I did. Will read on. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- 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] 8.4 release planning
Robert Haas writes: >> Yeah, people like certification, but they also like products that work. >> Did you stop reading before getting to my non-security-based complaints? > I read them, but I suspect they are issues that can be addressed. How > would any of this affect join removal, anyway? It would prevent us from making optimizations that assume foreign key constraints hold; which is a performance issue not a covert-channel issue. 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] 8.4 release planning
On Tue, 2009-01-27 at 11:36 -0500, Tom Lane wrote: > David Fetter writes: > > On Mon, Jan 26, 2009 at 03:12:02PM -0500, Tom Lane wrote: > >> I don't think this is correct. > > > I do. > > > People literally grab my shoulder and ask when we'll have it. > > Do these people understand the difference between HS and a complete > replication solution? Are they still as excited after you explain > the difference? Yes, I think they do. http://www.postgresql.org/community/survey.55 These people seem to understand also. Sync rep *is* important, but it opens up new classes of applications for us. As does SEP. Both of those are more speculative and harder to measure, but we've seen big impact before from this type of new feature. HS appeals to current users. Current users aren't so worried about new applications, they look forward to being able to run queries on their currently idle standby servers. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- 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] 8.4 release planning
"Joshua D. Drake" writes: > This is my take as well. This is very real, very scary things that are > being worked on. HS should only ship after a very, very long non change > cycle (meaning no significant bugs (or refactoring) found in HS patch > for X period of time)... say after a full 8.5 dev cycle. I do not want > to commit this patch and then have to yank it out 3 months from now. In general I'm for planning large features with the potential to break existing functionality going in the beginning of cycles. I don't think that's the same as "no changes" though. The reason we make changes is because they're believed to be for the better. The point in my mind is to get more people playing with the new feature in contexts that *aren't* expected by the developers. Developers are notoriously bad at testing their work no matter how diligent they are they just don't think of things they didn't anticipate when they're coding. (Which is only logical -- surely they would have just written it right the first time if they anticipated the problems...) > Lastly, the last time a developer told me two weeks it was 3 months. > Unless we get a written development plan that describes specifically > what, when, why and how long I am severely suspect that Heikki or Simon > have a clue on an actual deliverable time line (no offense guys). Well, Simon's been pretty impressively bang-on with his estimates for his *development* projects going back at least to async-commit. The *review* process, however, is inherently hard to estimate though. I doubt anyone will give Tom better than even odds on his side bet, even if that's our best estimate. Simon has been refactoring and recoding based on Heikki's suggestions as fast as he's been proposing them though. It seems the question isn't how fast Simon will get the work done so much as how many items we'll want to change before committing it. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- 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] 8.4 release planning
On Tue, Jan 27, 2009 at 11:36:02AM -0500, Tom Lane wrote: > David Fetter writes: > > On Mon, Jan 26, 2009 at 03:12:02PM -0500, Tom Lane wrote: > >> I don't think this is correct. > > > I do. > > > People literally grab my shoulder and ask when we'll have it. > > Do these people understand the difference between HS and a complete > replication solution? Yes, and those who don't catch on quickly. The difference between warm standby and hot is the difference between an idle resource which only consumes money to mitigate risk and a revenue-generating one. The former is for fat organizations with money to throw around, and the latter is for anybody who needs to scale reads. > Are they still as excited after you explain the difference? Yes. Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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] 8.4 release planning
On Mon, 2009-01-26 at 22:55 -0500, Tom Lane wrote: > Even accepting such a restriction, there's too much code in > core Postgres to let anyone feel very good about keeping the core free > of security leaks I see what you're saying, but we're trying to pass certification, not provide security in all cases. The security policy & its implementation is part of the wall, so its straightforward to say "don't do those things". Since both backups and plugins are not typically managed by unprivileged users, that seems reasonable. (And anyway, they should be using PITR :-). I'd rather see it go in now. It needs to be audited, and it might fail. If we put it in 8.5 and it still fails, we'll be in 8.6, which is far, far away and we shouldn't expect NEC to fund such a long range mission. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- 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] 8.4 release planning
Tom Lane writes: > Robert Haas writes: >>> Yeah, people like certification, but they also like products that work. >>> Did you stop reading before getting to my non-security-based complaints? > >> I read them, but I suspect they are issues that can be addressed. How >> would any of this affect join removal, anyway? > > It would prevent us from making optimizations that assume foreign key > constraints hold; which is a performance issue not a covert-channel > issue. It does seem weird to simply omit records rather than throw an error and require the user to use a where clause, even if it's something like WHERE pg_accessible(tab). I wonder if we need a special kind of relational integrity trigger which requires that the privileges on a source row be a superset of the privileges on the target row. Can you even test "superset" on these privileges? Or are they too general for that? And would you have trouble adjusting the privileges later because giving someone access to a label would require checking every row to see if they have access to every referenced row too? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- 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] 8.4 release planning
On Tue, 2009-01-27 at 11:49 -0500, Tom Lane wrote: > Robert Haas writes: > >> Yeah, people like certification, but they also like products that work. > >> Did you stop reading before getting to my non-security-based complaints? > > > I read them, but I suspect they are issues that can be addressed. How > > would any of this affect join removal, anyway? > > It would prevent us from making optimizations that assume foreign key > constraints hold; which is a performance issue not a covert-channel > issue. Well, only when sepostgresql = on. I would imagine Oracle has exactly the same issue. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- 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] 8.4 release planning
* Gregory Stark (st...@enterprisedb.com) wrote: > It does seem weird to simply omit records rather than throw an error and > require the user to use a where clause, even if it's something like WHERE > pg_accessible(tab). It is weird from an SQL perspective, I agree with you there. On the other hand, it's what the security community is looking for, and is what's implemented by other databases (Oracle, SQL Server...) that do row-level security and security labels. Requiring a where clause or you throw an error would certainly make porting applications that depend on that mechanism somewhat difficult, and doesn't really seem like it'd gain you all that much... Stephen signature.asc Description: Digital signature
Re: [HACKERS] 8.4 release planning
Robert Haas writes: > On Tue, Jan 27, 2009 at 11:49 AM, Tom Lane wrote: >> It would prevent us from making optimizations that assume foreign key >> constraints hold; which is a performance issue not a covert-channel >> issue. > Oh, I see now. That problem is going to be common to row-level DAC > and SE-PostgreSQL proper. It would not surprise me if any sort of > row-level access control turns out to be bad for performance, but > mainly because the overhead of checking permissions on every tuple is > bound to cost something. Right, but you expect that to be a small and predictable cost, say in the single-digits-percentage range. Plan optimizations that suddenly stop happening can cost you multiple orders of magnitude. And you won't soothe people by telling them that obsolete versions of Postgres would have been that slow all the time. 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] 8.4 release planning
On Tue, Jan 27, 2009 at 11:49 AM, Tom Lane wrote: > Robert Haas writes: >>> Yeah, people like certification, but they also like products that work. >>> Did you stop reading before getting to my non-security-based complaints? > >> I read them, but I suspect they are issues that can be addressed. How >> would any of this affect join removal, anyway? > > It would prevent us from making optimizations that assume foreign key > constraints hold; which is a performance issue not a covert-channel > issue. Oh, I see now. That problem is going to be common to row-level DAC and SE-PostgreSQL proper. It would not surprise me if any sort of row-level access control turns out to be bad for performance, but mainly because the overhead of checking permissions on every tuple is bound to cost something. If some day we have join removal and it has to be disabled when row-level access control is turned on, those users will be no worse off than they are today: no join removal. ...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] 8.4 release planning
On Tue, Jan 27, 2009 at 12:41:36PM -0500, Stephen Frost wrote: > * Gregory Stark (st...@enterprisedb.com) wrote: > > It does seem weird to simply omit records rather than throw an error and > > require the user to use a where clause, even if it's something like WHERE > > pg_accessible(tab). […] > do row-level security and security labels. Requiring a where clause > or you throw an error would certainly make porting applications that > depend on that mechanism somewhat difficult, and doesn't really seem > like it'd gain you all that much... Throwing an error would entail a side-channel leak that would not be acceptable to the security community, I bet. That said, I have reservations, along the lines of Peter E's, that the early design-level objections to the approach were never answered. I certainly never got any real answer to questions I asked, for what it's worth. I will note that I tried to have a look at the literature on this topic. As I started to read, it became obvious that it was copious, but pretty well-determined. What bothered me most about the answers I got was that there never seemed to be an answer to "please outline the design principles" except for "it's what SE-Linux does". The OS-level control rules seemed to me to be totally foreign to the database world, precisely because ACID is a problem in databases in a way it isn't for filesystems under the traditional UNIX model. I formed the impression -- only an impression, mind, that there was a poor fit between SE-Linux and database systems, and that the proponents had decided that enough caulk (in the form of "don't do that") would seal the gap. I haven't (obviously) been paying much attention to this topic since, but I detect something of the same sort of response in the recent discussion. Maybe the goal isn't explicit enough. If the goal is compliance with some set of well-defined tests, what are they? If the goal is buzzword compliance, what are the tests of that (to the extent there ever are some)? If the goal is just "security enhancement", I confess that I am still unable to understand the definitions of "security" and "enhancement" such that I think we have some operationalization of what the patch is supposed to provide. I know there are people who think this is cool. I guess, if I were running the circus, I'd want to know what's cool about it, and why. Then maybe the project would be in a position to understand whether that kind of cool is the way it wants to be. But without a clear problem statement, and a roadmap of how the patches solve the problem, I'm at a loss. And last I checked (which was, admittedly, not today), the project pages didn't have that information. A -- Andrew Sullivan a...@crankycanuck.ca -- 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] 8.4 release planning
Stephen Frost wrote: * Gregory Stark (st...@enterprisedb.com) wrote: It does seem weird to simply omit records rather than throw an error and require the user to use a where clause, even if it's something like WHERE pg_accessible(tab). The idea is for the level of informations security we're talking about, someone with limited permissions not only isn't allowed to know certain data, they're not allowed to know certain data *exists*. Within the SELinux framework, this is accomplished by hiding files you don't have permission to see, not merely denying access to them. The presumption is that if you know the data exists but can't access it directly, you'll use indirect methods to derive what it is. But if you don't even know it exists, then you won't look for it. There's a level above that which I don't think SEPostgres implements, which is data substitution, in which you see different data according to what security level you are. While this may seem insane for a business application, for military-support applications it makes some sense. --Josh -- 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] 8.4 release planning
Josh Berkus writes: > Stephen Frost wrote: > It does seem weird to simply omit records rather than throw an error > The presumption is that if you know the data exists but can't access it > directly, you'll use indirect methods to derive what it is. But if you > don't even know it exists, then you won't look for it. Right, which is why it's bad for something like a foreign key constraint to expose the fact that the row does exist after all. > There's a level above that which I don't think SEPostgres implements, > which is data substitution, in which you see different data according to > what security level you are. While this may seem insane for a business > application, for military-support applications it makes some sense. I think it might be possible to build such a thing using views, but I agree that the patch doesn't give it to you for free. 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] 8.4 release planning
Josh Berkus wrote: Stephen Frost wrote: * Gregory Stark (st...@enterprisedb.com) wrote: It does seem weird to simply omit records rather than throw an error and require the user to use a where clause, even if it's something like WHERE pg_accessible(tab). The idea is for the level of informations security we're talking about, someone with limited permissions not only isn't allowed to know certain data, they're not allowed to know certain data *exists*. Within the SELinux framework, this is accomplished by hiding files you don't have permission to see, not merely denying access to them. SELinux does not (and can not) hide the existence of files, as file names are part of the directory data and not part of the file data. We can restrict read on the directory so you can't see any of the file names but this is not a complete solution as anyone with search/create perms on the directory can enumerate the file name namespace to discover existence of files. We do not consider that a short coming, anyone who needs to hide existence of files needs to set up their directory structure to disallow read/search/create on the directories they aren't allowed to discover filenames in. Polyinstanciation can also address this issue. The presumption is that if you know the data exists but can't access it directly, you'll use indirect methods to derive what it is. But if you don't even know it exists, then you won't look for it. There are ways to mitigate this in the current security model of sepostgres, namely using trusted stored procedures to fetch data you are unwilling to let someone query against directly (or indirectly). Just as with SELinux anyone who needs this kind of capability would have to correctly design their tables and stored procedures to address their security goals. There's a level above that which I don't think SEPostgres implements, which is data substitution, in which you see different data according to what security level you are. While this may seem insane for a business application, for military-support applications it makes some sense. Trusted stored procedures can handle the above requirement, either by fuzzing data (consider coordinates x,y are in a table but below top secret you can't have access to the exact coordinates, the trusted stored procedure can fetch and fuzz them sufficiently before delivering them to the client). -- 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] 8.4 release planning
Tom Lane wrote: Josh Berkus writes: Stephen Frost wrote: It does seem weird to simply omit records rather than throw an error The presumption is that if you know the data exists but can't access it directly, you'll use indirect methods to derive what it is. But if you don't even know it exists, then you won't look for it. Right, which is why it's bad for something like a foreign key constraint to expose the fact that the row does exist after all. Once again, this is not an issue for us. We would much rather have a database that allows you to hide data from unauthorized clients using a mandatory policy than one that does nothing because you couldn't close some covert channels. I'll repeat what I said in an earlier email, SELinux doesn't (and can't) address all covert channels in Linux, and that is fine as long as it is understood and documented (which is part of the evaluation process). There's a level above that which I don't think SEPostgres implements, which is data substitution, in which you see different data according to what security level you are. While this may seem insane for a business application, for military-support applications it makes some sense. I think it might be possible to build such a thing using views, but I agree that the patch doesn't give it to you for free. -- 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] 8.4 release planning
Josh, We do not consider that a short coming, anyone who needs to hide existence of files needs to set up their directory structure to disallow read/search/create on the directories they aren't allowed to discover filenames in. Polyinstanciation can also address this issue. Hmmm. Why try to hide individual rows in tables then? That would seem not in keeping with the filesystem policies. --Josh -- 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] 8.4 release planning
Josh Berkus wrote: Josh, We do not consider that a short coming, anyone who needs to hide existence of files needs to set up their directory structure to disallow read/search/create on the directories they aren't allowed to discover filenames in. Polyinstanciation can also address this issue. Hmmm. Why try to hide individual rows in tables then? That would seem not in keeping with the filesystem policies. Because rows have data in them. It is analogous to not allowing the contents of the file to be visible. However, the primary key is still known to exist through various means, which is more analogous to the filename. -- 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] 8.4 release planning
On Tue, Jan 27, 2009 at 12:52 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Jan 27, 2009 at 11:49 AM, Tom Lane wrote: >>> It would prevent us from making optimizations that assume foreign key >>> constraints hold; which is a performance issue not a covert-channel >>> issue. > >> Oh, I see now. That problem is going to be common to row-level DAC >> and SE-PostgreSQL proper. It would not surprise me if any sort of >> row-level access control turns out to be bad for performance, but >> mainly because the overhead of checking permissions on every tuple is >> bound to cost something. > > Right, but you expect that to be a small and predictable cost, say in > the single-digits-percentage range. Plan optimizations that > suddenly stop happening can cost you multiple orders of magnitude. > And you won't soothe people by telling them that obsolete versions of > Postgres would have been that slow all the time. Well, look at it another way. If we don't accept row-level security into PostgreSQL, then people will have to implement it themselves. In fact, I currently have a real application that does exactly this. The row-filtering is done, in essence, by having the web application add certain conditions to the WHERE clause of certain queries depending on which user is making the request. And if those WHERE clauses happen to mention columns from table X, then table X won't be a candidate for join removal. The only difference is that the logic is in my app rather than in the database itself. To put that another way, row-level permissions are just another attribute of a table that could potentially affect the query result, and the impact of referring to that attribute will be exactly the same as the impact of referring to any other attribute in that table. ...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] 8.4 release planning
Andrew, * Andrew Sullivan (a...@crankycanuck.ca) wrote: > Throwing an error would entail a side-channel leak that would not be > acceptable to the security community, I bet. That said, I have > reservations, along the lines of Peter E's, that the early > design-level objections to the approach were never answered. I > certainly never got any real answer to questions I asked, for what > it's worth. I've added Joshua Brindle (hope that's alright, Josh), since I'm not sure if he's trying to follow this whole 'release planning' thread and your concerns are regarding SE-PostgreSQL. I hope he can help to address them (below). > I will note that I tried to have a look at the literature on this > topic. As I started to read, it became obvious that it was copious, > but pretty well-determined. What bothered me most about the answers I > got was that there never seemed to be an answer to "please outline the > design principles" except for "it's what SE-Linux does". The OS-level > control rules seemed to me to be totally foreign to the database > world, precisely because ACID is a problem in databases in a way it > isn't for filesystems under the traditional UNIX model. I formed the > impression -- only an impression, mind, that there was a poor fit > between SE-Linux and database systems, and that the proponents had > decided that enough caulk (in the form of "don't do that") would seal > the gap. > > I haven't (obviously) been paying much attention to this topic since, > but I detect something of the same sort of response in the recent > discussion. Maybe the goal isn't explicit enough. If the goal is > compliance with some set of well-defined tests, what are they? If the > goal is buzzword compliance, what are the tests of that (to the extent > there ever are some)? If the goal is just "security enhancement", I > confess that I am still unable to understand the definitions of > "security" and "enhancement" such that I think we have some > operationalization of what the patch is supposed to provide. > > I know there are people who think this is cool. I guess, if I were > running the circus, I'd want to know what's cool about it, and why. > Then maybe the project would be in a position to understand whether > that kind of cool is the way it wants to be. But without a clear > problem statement, and a roadmap of how the patches solve the problem, > I'm at a loss. And last I checked (which was, admittedly, not today), > the project pages didn't have that information. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] 8.4 release planning
Joshua Brindle writes: > Tom Lane wrote: >> Right, which is why it's bad for something like a foreign key constraint >> to expose the fact that the row does exist after all. > Once again, this is not an issue for us. Yes it is an issue; claiming it isn't doesn't make it so. You just stated, in effect, that you don't implement data hiding in the filesystem because it would break standard Unix filesystem semantics. How is that consistent with your opinion that it's okay to break standard SQL semantics in order to implement data hiding in a database? The question of whether there is a covert channel is only a small part of my complaint here. If it's the judgement of security experts that that's an acceptable thing, that's fine, it's their turf. But SQL behavior is my turf, and I'm not happy with discarding fundamental semantic properties. Quoting from your other message: > We do not consider that a short coming, anyone who needs to hide > existence of files needs to set up their directory structure to > disallow read/search/create on the directories they aren't allowed to > discover filenames in. This seems to me to be exactly parallel to deciding that SELinux should control only table/column permissions within SQL; an approach that would be enormously less controversial, less expensive, and more reliable than what SEPostgres tries to do. 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] 8.4 release planning
* Tom Lane (t...@sss.pgh.pa.us) wrote: > This seems to me to be exactly parallel to deciding that SELinux should > control only table/column permissions within SQL; an approach that would > be enormously less controversial, less expensive, and more reliable than > what SEPostgres tries to do. While also ignoring a feature that is available, and used by these same security communities, in other enterprise RDBMSs... http://www.securityfocus.com/infocus/1743 http://www.microsoft.com/technet/prodtechnol/sql/2005/multisec.mspx It's not codified in the SQL spec (yet..) that I saw, and maybe we could seperate out the SE bits from the row-level bits, but I'm really not sure I see the value in doing that.. Stephen signature.asc Description: Digital signature
Re: [HACKERS] 8.4 release planning
Stephen Frost wrote: > * Gregory Stark (st...@enterprisedb.com) wrote: >> It does seem weird to simply omit records rather than throw an error and >> require the user to use a where clause, even if it's something like WHERE >> pg_accessible(tab). > > It is weird from an SQL perspective, I agree with you there. On the > other hand, it's what the security community is looking for, and is > what's implemented by other databases (Oracle, SQL Server...) that > do row-level security and security labels. Requiring a where clause > or you throw an error would certainly make porting applications that > depend on that mechanism somewhat difficult, and doesn't really seem > like it'd gain you all that much... It seems to me that there are two different standards to which this feature might be held. Is the goal a) SEPostgres can provide useful rules to add security to some specific applications so long as you're careful to avoid crafting policies that produce bizarre behaviors (like avoiding restricing access to foreign key data you might need). On the other hand it gives you enough rope to hang yourself and produce weird results that don't make sense from a SQL standard point of view if you aren't careful matching the SEPostgres rules with your apps. or b) SEPostgreSQL should only give enough rope that you can not craft rules that produce unexpected behavior from a SQL point of view; and that it would be bad if one can produce SEPostgres policies that produce unexpected SQL behavior. It seems to me many of the security-enhanced products seem to do the former; while it seems some of the objections to this patch are more of the latter. -- 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] 8.4 release planning
Tom Lane wrote: Joshua Brindle writes: Tom Lane wrote: Right, which is why it's bad for something like a foreign key constraint to expose the fact that the row does exist after all. Once again, this is not an issue for us. Yes it is an issue; claiming it isn't doesn't make it so. You just stated, in effect, that you don't implement data hiding in the filesystem because it would break standard Unix filesystem semantics. We break plenty of standard semantics. Applications generally expect to be able to unlink files they can write to, to truncate or append. They expect read()/write() calls to succeed after a successful open(). SELinux is more fine grained than POSIX/UNIX is so some of these fundamental assumptions got broken. In the end this created better/safer software, after some growing pains of course. How is that consistent with your opinion that it's okay to break standard SQL semantics in order to implement data hiding in a database? Please step me through how the SQL semantics are being broken. From my perspective (I've used databases, written applications for them, etc but never hacked on a database server directly) this seems pretty straightforward. There already exists the possibility that you won't be able to read/write one or more of the tables for which a foreign key constraint exists, how do you handle it now? Why isn't it appropriate to handle it the same way? The question of whether there is a covert channel is only a small part of my complaint here. If it's the judgement of security experts that that's an acceptable thing, that's fine, it's their turf. But SQL behavior is my turf, and I'm not happy with discarding fundamental semantic properties. Quoting from your other message: We do not consider that a short coming, anyone who needs to hide existence of files needs to set up their directory structure to disallow read/search/create on the directories they aren't allowed to discover filenames in. This seems to me to be exactly parallel to deciding that SELinux should control only table/column permissions within SQL; an approach that would be enormously less controversial, less expensive, and more reliable than what SEPostgres tries to do. It isn't parallel though, in applications using the filesystem specifying directories where files go is fairly common. In database applications you expect all the data to be in the same table, having multiple tables with the same schema to try and separate out data that should be visible to some and not others isn't acceptable to most people and certainly wouldn't be compatible with many existing applications. Further, we have the ability to use per-process namespaces/polyinstantiation on the filesystem. From what I've heard that is somewhere you are unwilling to go as a community for postgresql so the options are somewhat more limited. I'm not trying to pretend that SELinux and sepostgresql are the same thing and always have to be treated the same. The trusted X work uses the same infrastructure and security policy language as sepostgres and selinux itself but noone is comparing windows and pointers to tables and rows. Type enforcement is a flexible system. You identify the objects that are important to you in the object manager (postgresql in this case) and assign types to it and write policies around those types. The SELinux community came to a consensus quite a while back about what objects were important to us. I had assumed (perhaps foolishly) that this had been communicated and also agreed upon in the postgresql community. If that wasn't the case I hope we can sit down and talk about the model to determine what objects are important to everyone and talk about the implementation details afterward. -- 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] 8.4 release planning
On Tue, 2009-01-27 at 13:57 -0500, Joshua Brindle wrote: > Josh Berkus wrote: > > Josh, > > > >> We do not consider that a short coming, anyone who needs to hide > >> existence of files needs to set up their directory structure to > >> disallow read/search/create on the directories they aren't allowed to > >> discover filenames in. Polyinstanciation can also address this issue. > > > > Hmmm. Why try to hide individual rows in tables then? That would seem > > not in keeping with the filesystem policies. > > > > Because rows have data in them. It is analogous to not allowing the contents > of > the file to be visible. However, the primary key is still known to exist > through > various means, which is more analogous to the filename. Since most keys are likely to be non-meaningful IDs, its not going to help you much. And besides, all you have to do is reserve key ranges for different security levels so there would never be any overlap. So its not really even a difficult problem to get around. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- 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] 8.4 release planning
Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: This seems to me to be exactly parallel to deciding that SELinux should control only table/column permissions within SQL; an approach that would be enormously less controversial, less expensive, and more reliable than what SEPostgres tries to do. While also ignoring a feature that is available, and used by these same security communities, in other enterprise RDBMSs... http://www.securityfocus.com/infocus/1743 http://www.microsoft.com/technet/prodtechnol/sql/2005/multisec.mspx It's not codified in the SQL spec (yet..) that I saw, and maybe we could seperate out the SE bits from the row-level bits, but I'm really not sure I see the value in doing that.. They are separate. If you look at the patches you'll see a pgace part, this is where the core interfaces to the security backends, and you'll see a rowacl backend and an sepgsql backend. Personally I'd like to see all of the access control moved out to use pgace, including the standard DAC permissions but I doubt that would never happen. -- 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] 8.4 release planning
Ron Mayer wrote: Stephen Frost wrote: * Gregory Stark (st...@enterprisedb.com) wrote: It does seem weird to simply omit records rather than throw an error and require the user to use a where clause, even if it's something like WHERE pg_accessible(tab). It is weird from an SQL perspective, I agree with you there. On the other hand, it's what the security community is looking for, and is what's implemented by other databases (Oracle, SQL Server...) that do row-level security and security labels. Requiring a where clause or you throw an error would certainly make porting applications that depend on that mechanism somewhat difficult, and doesn't really seem like it'd gain you all that much... It seems to me that there are two different standards to which this feature might be held. Is the goal a) SEPostgres can provide useful rules to add security to some specific applications so long as you're careful to avoid crafting policies that produce bizarre behaviors (like avoiding restricing access to foreign key data you might need). On the other hand it gives you enough rope to hang yourself and produce weird results that don't make sense from a SQL standard point of view if you aren't careful matching the SEPostgres rules with your apps. This is what we like to call a flexible mandatory access control system, such as type enforcement. Give everything a type, write rules around the types. If you mess up your system may not boot (or your database queries might be strange). In talking to KaiGai the rules should not allow you to create inconsistencies, however. If you delete a row with a foreign key constraint and you cannot delete the associated row in another table the whole operation should fail. We want to fail on the side of maintaining data integrity and consistency while still allowing you enough rope to have a fine grained, flexible access control system. or b) SEPostgreSQL should only give enough rope that you can not craft rules that produce unexpected behavior from a SQL point of view; and that it would be bad if one can produce SEPostgres policies that produce unexpected SQL behavior. SELinux (and associated security aware applications) tend to go the way of very fine grained and let the policy author decide how to use it. I've seen SELinux policies with as few as 3 types, to as many as 3000. It is up to the policy author to choose the granularity appropriate for their purpose. I'd hate to see arbitrary limits put on the policy because of applications that might now operate correctly if they get an unexpected error (the applications should be fixed, not the security policy crippled) It seems to me many of the security-enhanced products seem to do the former; while it seems some of the objections to this patch are more of the latter. Historically trusted systems were fairly course grained, with only Bell and LaPadula policies[1]. SELinux is probably the first fine grained mandatory access control system in the mainstream. 1 http://en.wikipedia.org/wiki/Bell-LaPadula_model -- 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] 8.4 release planning
On Tue, Jan 27, 2009 at 2:18 PM, Tom Lane wrote: > Joshua Brindle writes: >> Tom Lane wrote: >>> Right, which is why it's bad for something like a foreign key constraint >>> to expose the fact that the row does exist after all. > >> Once again, this is not an issue for us. > > Yes it is an issue; claiming it isn't doesn't make it so. You just > stated, in effect, that you don't implement data hiding in the > filesystem because it would break standard Unix filesystem semantics. > How is that consistent with your opinion that it's okay to break > standard SQL semantics in order to implement data hiding in a database? I think you're being pedantic. There are different levels of breakage and it is a matter of finding one that produces an acceptable cost-benefit trade-off. ISTM that we have plenty of evidence on these threads that other databases do things in a way that is similar to what SE-PostgreSQL is proposing to do. If people are using the feature in Oracle and getting value out of it, why should it suddenly become useless when ported to PostgreSQL? BTW, Oracle also has join removal, which proves that it isn't impossible for a high-quality database product to support both features. ...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] 8.4 release planning
On Tue, 2009-01-27 at 14:18 -0500, Tom Lane wrote: > Joshua Brindle writes: > > Tom Lane wrote: > >> Right, which is why it's bad for something like a foreign key constraint > >> to expose the fact that the row does exist after all. > > > Once again, this is not an issue for us. > > Yes it is an issue > The question of whether there is a covert channel is only a small part > of my complaint here. If it's the judgement of security experts that > that's an acceptable thing, that's fine, it's their turf. But SQL > behavior is my turf, and I'm not happy with discarding fundamental > semantic properties. Why did we bother to invite Joshua here if we aren't going to listen to him? Thanks for coming to help Joshua, much appreciated. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- 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] 8.4 release planning
Robert Haas writes: > On Tue, Jan 27, 2009 at 12:52 PM, Tom Lane wrote: >> Right, but you expect that to be a small and predictable cost, say in >> the single-digits-percentage range. Plan optimizations that >> suddenly stop happening can cost you multiple orders of magnitude. > Well, look at it another way. If we don't accept row-level security > into PostgreSQL, then people will have to implement it themselves. In > fact, I currently have a real application that does exactly this. The > row-filtering is done, in essence, by having the web application add > certain conditions to the WHERE clause of certain queries depending on > which user is making the request. And if those WHERE clauses happen > to mention columns from table X, then table X won't be a candidate for > join removal. The only difference is that the logic is in my app > rather than in the database itself. > To put that another way, row-level permissions are just another > attribute of a table that could potentially affect the query result, > and the impact of referring to that attribute will be exactly the same > as the impact of referring to any other attribute in that table. The flaw in that argument is that as you are doing it, the de-optimization only happens on queries that actually need the behavior. As the SEPostgres patch is constructed, the planner could *never* trust an FK for optimization since it would have no way to know whether row level permissions might be present (perhaps only for some rows) at execution time. You could only get back the optimization in builds with SEPostgres compiled out. That's pretty nasty, especially for packagers who have to decide which build setting will displease fewer users. 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] 8.4 release planning
Tom Lane wrote: >> We do not consider that a short coming, anyone who needs to hide >> existence of files needs to set up their directory structure to >> disallow read/search/create on the directories they aren't allowed to >> discover filenames in. > > This seems to me to be exactly parallel to deciding that SELinux should > control only table/column permissions within SQL; an approach that would > be enormously less controversial, less expensive, and more reliable than > what SEPostgres tries to do. With the table/column approach, could users who needed some row-level capabilities work around this easily by setting table-level access control on partitions? In some ways that seems like it'd be easier to manage as well. -- 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] 8.4 release planning
* Joshua Brindle (met...@manicmethod.com) wrote: > They are separate. If you look at the patches you'll see a pgace part, > this is where the core interfaces to the security backends, and you'll > see a rowacl backend and an sepgsql backend. Right, guess it wasn't clear to me that the PGACE bits for row-level access control could be used independently of SELinux (and maybe even on systems that don't have SELinux..?). > Personally I'd like to see all of the access control moved out to use > pgace, including the standard DAC permissions but I doubt that would > never happen. Yeah... That's a whole 'nother discussion. Stephen signature.asc Description: Digital signature
Re: [HACKERS] 8.4 release planning
Stephen Frost wrote:
* Joshua Brindle (met...@manicmethod.com) wrote:
They are separate. If you look at the patches you'll see a pgace part,
this is where the core interfaces to the security backends, and you'll
see a rowacl backend and an sepgsql backend.
Right, guess it wasn't clear to me that the PGACE bits for row-level
access control could be used independently of SELinux (and maybe even on
systems that don't have SELinux..?).
Sure, if you look at pgaceHooks.c you'll see:
bool
pgaceExecScan(Scan *scan, Relation rel, TupleTableSlot *slot)
{
/* Hardwired DAC checks */
if (!rowaclExecScan(scan, rel, slot))
return false;
switch (pgace_feature)
{
#ifdef HAVE_SELINUX
case PGACE_FEATURE_SELINUX:
if (sepgsqlIsEnabled())
return sepgsqlExecScan(scan, rel, slot);
break;
#endif
default:
break;
}
return true;
}
Notice the rowacl call outside of the HAVE_SELINUX ifdefs
--
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] 8.4 release planning
Ron Mayer writes: > It seems to me that there are two different standards to which this feature > might be held. > Is the goal > a) SEPostgres can provide useful rules to add security to some > specific applications so long as you're careful to avoid crafting > policies that produce bizarre behaviors (like avoiding restricing > access to foreign key data you might need). On the other hand it > gives you enough rope to hang yourself and produce weird results > that don't make sense from a SQL standard point of view if you > aren't careful matching the SEPostgres rules with your apps. > or > b) SEPostgreSQL should only give enough rope that you can not > craft rules that produce unexpected behavior from a SQL point > of view; and that it would be bad if one can produce SEPostgres > policies that produce unexpected SQL behavior. With my other hat on (the red one) what I'm concerned about is whether this patch will ever produce a feature that I could turn on in the standard Red Hat/Fedora build of Postgres. Right at the moment it seems that the potential performance hit, for users who are *not using* SEPostgres but merely have to use a build in which it is present, might be bad enough to guarantee that that will never happen. 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] 8.4 release planning
> The flaw in that argument is that as you are doing it, the > de-optimization only happens on queries that actually need the behavior. > As the SEPostgres patch is constructed, the planner could *never* trust > an FK for optimization since it would have no way to know whether row > level permissions might be present (perhaps only for some rows) at > execution time. You could only get back the optimization in builds with > SEPostgres compiled out. That's pretty nasty, especially for packagers > who have to decide which build setting will displease fewer users. OK, I think I am starting to understand your concern now. My understanding of how the world works is SE-PostgreSQL would always be compiled in but could be turned off at run-time with a GUC. I know that the original design called for a compile-time switch, but everyone hated it and I am pretty sure KaiGai changed it. If he hasn't, he will. :-) There was also talk of having a table-level option to include/exclude the security ID (I'm not sure if it's currently implemented that way). Obviously that wouldn't be relevant for row-level MAC (because presumably you would need/want that turned on for all tables) but it would be very relevant for row-level DAC (because it's easy, at least for me, to imagine that you would only turn this on for a subset, possibly quite a small subset, of your tables where you knew that it was really needed). If, by default, we make sepostgresql disabled, MAC security IDs on newly created tables off, and DAC security IDs on newly created tables off, then the pain will be confined to people who explicitly request sepostgresql or row-level DAC. ...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] 8.4 release planning
Simon Riggs writes: > On Tue, 2009-01-27 at 13:57 -0500, Joshua Brindle wrote: >> Josh Berkus wrote: >>> Hmmm. Why try to hide individual rows in tables then? That would seem >>> not in keeping with the filesystem policies. >> >> Because rows have data in them. It is analogous to not allowing the contents >> of >> the file to be visible. However, the primary key is still known to exist >> through >> various means, which is more analogous to the filename. > Since most keys are likely to be non-meaningful IDs, its not going to > help you much. Even more to the point: if the expectation is that you can hide a row's data payload but not its primary key, you can accomplish that with column-level permissions, without having to get into any non-standard or even faintly surprising SQL behavior, 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] 8.4 release planning
Tom Lane wrote: Simon Riggs writes: On Tue, 2009-01-27 at 13:57 -0500, Joshua Brindle wrote: Josh Berkus wrote: Hmmm. Why try to hide individual rows in tables then? That would seem not in keeping with the filesystem policies. Because rows have data in them. It is analogous to not allowing the contents of the file to be visible. However, the primary key is still known to exist through various means, which is more analogous to the filename. Since most keys are likely to be non-meaningful IDs, its not going to help you much. Even more to the point: if the expectation is that you can hide a row's data payload but not its primary key, you can accomplish that with column-level permissions, without having to get into any non-standard or even faintly surprising SQL behavior, We aren't saying we want to hide the payload of the data in an entire column, just the data in some of the rows. For example, if you have top secret and secret data in the same table a secret user would be able to see the entire row for secret rows but maybe only some of the data on the top secret rows (or maybe not see the rows at all). Further, the top secret rows may have some fields that are inaccessible but are accessible through a trusted stored procedure that does fuzzing on the data (back to the coordinates example I used earlier) -- 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] 8.4 release planning
On Tuesday 27 January 2009 16:48:21 Sam Mason wrote: > > though at EAL1 they're quite far from the EAL4+ that DB2, > > Oracle, etc get. > > As far as I understand, the different levels are about assuring a > set of code/features to some assurance level. The Wikipedia page[1] > gives a reasonable overview of the levels, but basically EAL1 says > that a limited amount of effort (in practical terms, several person > months/years of time for something like PG) was put in, EAL1 pretty much means, a test suite exists and passes. So that was easy. :-) -- 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] 8.4 release planning
On Tuesday 27 January 2009 16:36:50 Stephen Frost wrote: > * Peter Eisentraut (pete...@gmx.net) wrote: > > As one of the earlier reviewers, I think the design is OK, but the way > > the implementation is presented was not acceptable, and very little has > > been accomplished in terms of reacting to our comments. For example, > > where is the SQL row security feature, which should have been designed, > > implemented, and committed separately, in the opinion of most > > commentaries. > > Eh? Are you thinking of column-level privileges, which was committed > last week? No. > The SQL spec doesn't define row-level security, and coming > up with something willy-nilly on our own doesn't really strike me as the > best approach. Exactly. But there is plenty of discussion on that elsewhere. -- 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] 8.4 release planning
Ron Mayer writes: > Tom Lane wrote: >> This seems to me to be exactly parallel to deciding that SELinux should >> control only table/column permissions within SQL; an approach that would >> be enormously less controversial, less expensive, and more reliable than >> what SEPostgres tries to do. > With the table/column approach, could users who needed some row-level > capabilities work around this easily by setting table-level access > control on partitions? Yeah, the same thing had just occurred to me. We currently throw an error if a user doesn't have permissions on every partition (child table), but perhaps that behavior could be adjusted. Ignoring unreadable children would provide behavior pretty similar to that proposed by SEPostgres. To some extent that just postpones the semantic pain until the day when we try to do unique and FK constraints that span partitions. However, I think (after only minimal thought) that that will only re-introduce the covert-channel issue, which Joshua has already stated to be acceptable. 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] 8.4 release planning
Tom Lane wrote:
Ron Mayer writes:
It seems to me that there are two different standards to which this feature
might be held.
Is the goal
a) SEPostgres can provide useful rules to add security to some
specific applications so long as you're careful to avoid crafting
policies that produce bizarre behaviors (like avoiding restricing
access to foreign key data you might need). On the other hand it
gives you enough rope to hang yourself and produce weird results
that don't make sense from a SQL standard point of view if you
aren't careful matching the SEPostgres rules with your apps.
or
b) SEPostgreSQL should only give enough rope that you can not
craft rules that produce unexpected behavior from a SQL point
of view; and that it would be bad if one can produce SEPostgres
policies that produce unexpected SQL behavior.
With my other hat on (the red one) what I'm concerned about is whether
this patch will ever produce a feature that I could turn on in the
standard Red Hat/Fedora build of Postgres. Right at the moment it seems
that the potential performance hit, for users who are *not using*
SEPostgres but merely have to use a build in which it is present,
might be bad enough to guarantee that that will never happen.
According to the comments in security/sepgsql/core.c:
/*
* sepgsqlIsEnabled
*
* This function returns the state of SE-PostgreSQL when PGACE hooks
* are invoked, to prevent to call sepgsql() functions when
* SE-PostgreSQL is disabled.
*
* We can config the state of SE-PostgreSQL in $PGDATA/postgresql.conf.
* The GUC option "sepostgresql" can have the following four parameter.
*
* - default: It always follows the in-kernel SELinux state. When it
*works in Enforcing mode, SE-PostgreSQL also works in
*Enforcing mode. Changes of in-kernel state are delivered
*to userspace SE-PostgreSQL soon, and SELinux state
*monitoring process updates it rapidly.
* - enforcing : It always works in Enforcing mode. In-kernel SELinux
*has to be enabled.
* - permissive : It always works in Permissive mode. In-kernel SELinux
*has to be enabled.
* - disabled : It disables SE-PostgreSQL feature. It works as if
*original PostgreSQL
*/
and in the hooks there is a pgace_feature that turns off the checks:
void
pgaceGramAlterRelation(Relation rel, HeapTuple tuple, DefElem *defel)
{
switch (pgace_feature)
{
#ifdef HAVE_SELINUX
case PGACE_FEATURE_SELINUX:
if (sepgsqlIsEnabled())
{
sepgsqlGramAlterRelation(rel, tuple, defel);
return;
}
break;
#endif
default:
break;
}
if (defel)
ereport(ERROR,
(errcode(ERRCODE_PGACE_ERROR),
errmsg("unable to set security attribute of
table "
"via ALTER TABLE")));
}
So the pgace_feature turns off the backend call, there is an extra function
call, and a branch but that shouldn't cause the kind of performance degradation
you are talking about.
--
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] 8.4 release planning
On Tuesday 27 January 2009 19:10:40 Gregory Stark wrote: > It does seem weird to simply omit records rather than throw an error and > require the user to use a where clause, even if it's something like WHERE > pg_accessible(tab). Not to pick on you personally, but this is the kind of review that should have happened six months ago, not during a "why is our development process inadequate" discussion on the eve of beta. -- 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] 8.4 release planning
Peter Eisentraut writes: > Not to pick on you personally, but this is the kind of review that should > have > happened six months ago, not during a "why is our development process > inadequate" discussion on the eve of beta. Right now, today, in this thread, is the first time that we've had any opportunity to debate the design of SEPostgres with knowledgeable people other than KaiGai-san. It would likely be better if we started a new thread with a more appropriate title, but I see nothing wrong with asking pretty fundamental questions. 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] 8.4 release planning
* Peter Eisentraut (pete...@gmx.net) wrote: > > The SQL spec doesn't define row-level security, and coming > > up with something willy-nilly on our own doesn't really strike me as the > > best approach. > > Exactly. But there is plenty of discussion on that elsewhere. That's the nice thing about the SE-PostgreSQL patch.. It's at least following established row-level security setups in other enterprise RDBMSs... The folks coming out now and saying we should require using a WHERE clause or similar would cause a serious deviation from what's being done today, without any real change or advantage that I see.. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] 8.4 release planning
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Peter Eisentraut writes: > > Not to pick on you personally, but this is the kind of review that should > > have > > happened six months ago, not during a "why is our development process > > inadequate" discussion on the eve of beta. > > Right now, today, in this thread, is the first time that we've had any > opportunity to debate the design of SEPostgres with knowledgeable people > other than KaiGai-san. It would likely be better if we started a new > thread with a more appropriate title, but I see nothing wrong with > asking pretty fundamental questions. I agree with asking the questions, but I don't like the immediate assumption that we're going to have to kick the patch because someone asked a question or suggested an alternative design unless we actively decide that's the approach we want to go and it requires a serious rework of the patch. Personally, I think it'd be terrible to implement the suggestion that started this sub-thread since it breaks with what is currently done elsewhere and what the users of this feature would expect. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] 8.4 release planning
Peter Eisentraut writes: > On Tuesday 27 January 2009 16:36:50 Stephen Frost wrote: >> The SQL spec doesn't define row-level security, and coming >> up with something willy-nilly on our own doesn't really strike me as the >> best approach. > Exactly. But there is plenty of discussion on that elsewhere. BTW, whilst we are being beat about the head and shoulders with how Oracle et al already have features like this, it is entirely appropriate to wonder how come it's not in the standard. Those companies surely pretty much control the standards committee, and they have managed to push a ton of rather dubious things into the last couple of SQL updates. If row-level security is such a mess that they couldn't standardize it, that tells me something. 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] 8.4 release planning
Stephen Frost writes: > Personally, I think it'd be terrible to implement the suggestion that > started this sub-thread since it breaks with what is currently done > elsewhere and what the users of this feature would expect. Upthread we were being told that this patch breaks new ground and will offer capability available nowhere else. Now I'm hearing that it's just a "me too" patch to catch up with capability already available from N commercial vendors. Which is it? 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] 8.4 release planning
* Tom Lane (t...@sss.pgh.pa.us) wrote: > BTW, whilst we are being beat about the head and shoulders with how > Oracle et al already have features like this, it is entirely appropriate > to wonder how come it's not in the standard. Those companies surely > pretty much control the standards committee, and they have managed to > push a ton of rather dubious things into the last couple of SQL updates. > If row-level security is such a mess that they couldn't standardize it, > that tells me something. For my 2c, for whatever it's worth, it's a combination of a specialized user base and the fact that this kind of security used to only be in a seperate product (eg: Trusted Oracle). Perhaps it will be in the standard some day, I don't think it's unreasonable to think that. Certainly it'd be nice if it was already there. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] 8.4 release planning
Tom Lane wrote: Stephen Frost writes: Personally, I think it'd be terrible to implement the suggestion that started this sub-thread since it breaks with what is currently done elsewhere and what the users of this feature would expect. Upthread we were being told that this patch breaks new ground and will offer capability available nowhere else. Now I'm hearing that it's just a "me too" patch to catch up with capability already available from N commercial vendors. Which is it? It is like the difference between Trusted Solaris (really all the old trusted OS's) and SELinux. They both implement mandatory access control and both implement Bell and LaPadula as needed by the government/military but SELinux, via type enforcement, goes further to provide a completely flexible mandatory access control system. SELinux is useful to meet all sorts of security goals, from system and application integrity to data pipelining and confidentiality. The SELinux community believes this sort of access control is important to not only the military but commercial and even small scale systems. Further, because sepostgresql integrates well with SELinux the same system wide access controls flow seamlessly into the database. Are you able to access secret data on the filesystem? If so you'll be able to access secret data in the database. Are you able to update accounting information in the filesystem? Then you'll be able to update accounting information in the database. This also integrates with KaiGai's other work to SELinux-ize apache so that an apache server can run a user script from a users home directory and a type transition occurs to run the script in the appropriate domain for that user, then when that script accesses the database they'll have only the access that users script should have. This kind of end-to-end integration with mandatory access control is certainly ground breaking and isn't just the same ol' same ol' that other database vendors are doing (and have been doing for quite some time). -- 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] 8.4 release planning
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Personally, I think it'd be terrible to implement the suggestion that > > started this sub-thread since it breaks with what is currently done > > elsewhere and what the users of this feature would expect. > > Upthread we were being told that this patch breaks new ground and will > offer capability available nowhere else. Now I'm hearing that it's just > a "me too" patch to catch up with capability already available from N > commercial vendors. Which is it? argh, it's a combination, in the end. Oracle and SQL Server offer row level security, that's something we don't have today and is provided through PGACE and is a big piece of the security labels/context part of the high security RDBMS world. Neither of them (far as I know..) interoperate with a OS-level policy system to provide that additional integration with the rest of the system as a whole (the SE-Linux bits). I wasn't sure how easy they were to seperate and to use seperately. It looks like they can be used independently, which is great, and means you could implement row level security on a BSD platform, but you wouldn't get the integration with the OS policy unless you hooked in with the Trusted BSD system (which I think actually can be done through an SE-Linux userland port.. but I've never played with it). Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] 8.4 release planning
On Tue, 2009-01-27 at 15:03 -0500, Tom Lane wrote: > > With my other hat on (the red one) what I'm concerned about is whether > this patch will ever produce a feature that I could turn on in the > standard Red Hat/Fedora build of Postgres. FWIW, as you know, sepostgresql is already included in Fedora. You can continue shipping it as a seperate RPM set. -- Devrim GÜNDÜZ, RHCE devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org signature.asc Description: This is a digitally signed message part
Re: [HACKERS] 8.4 release planning
Devrim GÜNDÜZ wrote: On Tue, 2009-01-27 at 15:03 -0500, Tom Lane wrote: With my other hat on (the red one) what I'm concerned about is whether this patch will ever produce a feature that I could turn on in the standard Red Hat/Fedora build of Postgres. FWIW, as you know, sepostgresql is already included in Fedora. You can continue shipping it as a seperate RPM set. That is non-ideal. Getting the capability in to the standard database shipped with RHEL is very important to me and my customers. Since you can turn this off with GUC I don't see why it makes sense to ship 2 databases (nevermind the maintenance issues) -- 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] 8.4 release planning
* Devrim GÜNDÜZ (dev...@gunduz.org) wrote: > On Tue, 2009-01-27 at 15:03 -0500, Tom Lane wrote: > > With my other hat on (the red one) what I'm concerned about is whether > > this patch will ever produce a feature that I could turn on in the > > standard Red Hat/Fedora build of Postgres. > > FWIW, as you know, sepostgresql is already included in Fedora. You can > continue shipping it as a seperate RPM set. hrmpf, I wonder if that's why RH hasn't been as interested in pushing for inclusion upstream... Maybe the feel that's a workable solution? I wouldn't agree... but I don't run RH. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] 8.4 release planning
On Tue, 2009-01-27 at 15:46 -0500, Tom Lane wrote: > Peter Eisentraut writes: > > Not to pick on you personally, but this is the kind of review that should > > have > > happened six months ago, not during a "why is our development process > > inadequate" discussion on the eve of beta. > > Right now, today, in this thread, is the first time that we've had any > opportunity to debate the design of SEPostgres with knowledgeable people > other than KaiGai-san. It would likely be better if we started a new > thread with a more appropriate title, but I see nothing wrong with > asking pretty fundamental questions. Except that Bruce and I already checked detailed documentation references on this very topic months ago. Check with Bruce; he was careful to point those things out to me, so I'm sure he'll do the same for you. I'm satisfied, on this point. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- 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] 8.4 release planning
On Mon, Jan 26, 2009 at 08:28:32PM -0500, Tom Lane wrote: > Hmm, you think selinux people read pgsql-announce? Maybe not, but it got it onto LWN, which is a lot more people. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines. signature.asc Description: Digital signature
Re: [HACKERS] 8.4 release planning
Joshua Brindle wrote: >> FWIW, as you know, sepostgresql is already included in Fedora. You can >> continue shipping it as a seperate RPM set. > > That is non-ideal. Getting the capability in to the standard database > shipped with RHEL is very important to me and my customers. Could you speak - even in general terms - about who your customers are and what kinds of needs (is row-level acls the most important to them? mandantory access control at the table level? both?) they have? I'm guessing a better understanding of how real-world users would use this feature would be enlightening. > Since you can turn this off with GUC I don't see why it makes sense to > ship 2 databases (nevermind the maintenance issues) -- 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] 8.4 release planning
On Monday 26 January 2009 15:13:56 dp...@pgadmin.org wrote: > On 1/26/09, Josh Berkus wrote: > > All, > > > >>> 1) having the last CF on Nov. 1 was a mistake. That put us square in > >>> the path of the US & Christian holidays during the critical integration > >>> phase .. > >>> which means we haven't really had 3 months of integration, we've had > >>> *two*. > > > > Actually, I'm thinking about this again, and made a mistake about the > > mistake. The *original plan* was that we were not going to accept any > > new patches for Nov-CF. Just revised patches from eariler Fests. We > > didn't stick to that, which is mostly why we are still reviewing now. > > I don't recall us discussing that, but it sounds like it might help next > cycle. > What would be the significance of opening up the tree to future development between the last commitfest and last commitfest -1, if no new patches could be introduced? Essentially this is where we are at now... November commit fest finished, December we "re-opened" for development, and we're in the January commitfest where no new features have been accepted. The problem is what to do when we get to the end of the commit fests, and we have a few reamining (invariably large/complex) patches that people don't want to push. I had been leaning toward the idea of pushing the 8.4 release back six months, but reopening development for 2-3 more development/commitfest cycles, but I am starting to think this is moving things in the wrong direction. Now I am starting to think that we cannot prevent large patches from showing up at the end of a cycle no matter what, and the only way to really "solve" that problem is to lesson the pain of getting bumped from a release. Ie. instead of being bump meaning you must wait 12-14 months till next release, we move toward more of a 6 month cycle of development. I'm not sure it's feasible to boil down beta/rc phase to two months, tough it seems possible if we were strict about bumping features that aren't ready, and if our development cycles only went 4 months. For end users who are concerned about continuous upgrading, we might think about putting restrictions on every other release (ie. require binary or data file level compatability with 8.4 for the 8.5 release, and remove that restriction for 8.6) to lesson the upgrade path. (alternativly, a working IPU plan could make that less of an issue) -- 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] 8.4 release planning
On Tuesday 27 January 2009 11:56:51 Simon Riggs wrote: > On Tue, 2009-01-27 at 11:36 -0500, Tom Lane wrote: > > David Fetter writes: > > > On Mon, Jan 26, 2009 at 03:12:02PM -0500, Tom Lane wrote: > > >> I don't think this is correct. > > > > > > I do. > > > > > > People literally grab my shoulder and ask when we'll have it. > > > > Do these people understand the difference between HS and a complete > > replication solution? Are they still as excited after you explain > > the difference? > > Yes, I think they do. > > http://www.postgresql.org/community/survey.55 > These people seem to understand also. > > Sync rep *is* important, but it opens up new classes of applications for > us. As does SEP. Both of those are more speculative and harder to > measure, but we've seen big impact before from this type of new feature. > > HS appeals to current users. Current users aren't so worried about new > applications, they look forward to being able to run queries on their > currently idle standby servers. > That's modest. I've talked to several oracle and db2 shops that want a standby for reporting that has relatively easy setup/maintenance (handling ddl is a big part of this) and the HS feature your working on will give them something as good as what they are getting now. So yeah, HS appeals to future users as well. -- 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] 8.4 release planning
That's modest. I've talked to several oracle and db2 shops that want a standby for reporting that has relatively easy setup/maintenance (handling ddl is a big part of this) and the HS feature your working on will give them something as good as what they are getting now. So yeah, HS appeals to future users as well. I've talked to some of my clients, and while they *want* synch or near-synch HS, even slow HS is useful to them *now*. One client is planning on deploying a rather complex FS cloning infrastructure just to have a bunch of reporting, testing and read-only search databases they need. They'd be thrilled with an HS feature which produced DBs which were an hour out of date (or even 6 hours out of date), but ran read-only queries. --Josh. -- 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] 8.4 release planning
On 1/27/09 4:40 PM, "Ron Mayer" wrote: > Joshua Brindle wrote: >>> FWIW, as you know, sepostgresql is already included in Fedora. You can >>> continue shipping it as a seperate RPM set. >> >> That is non-ideal. Getting the capability in to the standard database >> shipped with RHEL is very important to me and my customers. > > Could you speak - even in general terms - about who your customers are > and what kinds of needs (is row-level acls the most important to them? > mandantory access control at the table level? both?) they have? > I'll speak to this a bit (Josh is also a Tresys employee). I can't say who my customers are, but I can speak to their needs. They really need row-level mandatory access controls (so both). I'll give a few examples that will hopefully help here. 1) One customer had several networks, each with a different classification. When a user needed to find anything, it was very painful as they would have to log into each network one at a time to search for anything. What they wanted to do was have a trusted database with a combined index of all the networks. They wanted to be able to write a flexible policy that could grant access to individual entries in the database based on what network the request came from in addition to the security clearance of the user requesting data. 2) Another example that we've been asked for repeatedly but had to turn away as the capability did not yet exist is a trusted LAMP/LAPP stack (Note that KaiGai is also working on the apache portion of this to provide a complete trusted LAPP stack). Under this model, individual web scripts can be run with a specific type. Combined with an SE-PostgreSQL policy, this gives the ability to restrict what a specific script can access. Additionally, as SE-PostgreSQL ties back in to the operating system mandatory access control mechanism, we can tie the type of the script back to the type of the actual user making the request. Coupled with labeled IPSec, this means we can control access to data in the database based on the clearance or role (or anything else you want to represent in their type) of the user on their end system. 3) A customer wanted to implement an approval process that required several steps. Without SE-PostgreSQL, we were forced to implement this by making lots of copies. Stage 1 would approve the package and copy it into Stage 2's inbox. We would grant each stage write access to the next stage's inbox in order to enforce information flow. This was very expensive, and didn't scale well. With SE-PostgreSQL, we could leave the data where it was and simply relabel the row(s). Each stage would be granted the ability to relabel from its type to the type of the next stage. No copies are necessary. I hope those help. I realize that many of you may not be used to dealing with customers who have such stringent security requirements, but if SE-PostgreSQL gets merged, that could change. Thanks, Chad Sellers -- 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] 8.4 release planning
On Tuesday 27 January 2009 10:34:59 Joshua D. Drake wrote: > On Tue, 2009-01-27 at 06:40 +0100, Pavel Stehule wrote: > > > 8.4-stable > > > 8.4-experimental > > > > > > stable is everything that stable is. PostgreSQL at its best. > > > > I dislike this idea - it's same like short processed 8.5 - > > Actually it isn't because we wouldn't accept features into > 8.4-experimental. The only thing we would accept into 8.4-experimental > would be bug fixes that would automatically be ported up to 8.5 (or > perhaps the other way around). We would still continue to build 8.5 as > normal. > > > that is > > more simple. > > We have tried the short release cycle before, it was called 8.2. It > fails, remarkably. > I think this is a bit of revisionsit history. While I'd agree it didn't work, the cycle was shorter... or to put it another way, would you say that the commitfest model failed miserably? should we scrap that for next cycle? I wonder... Feb 1 - all remaining patches bump / beta starts March 15th - beta ends / rc starts (note, giving 3 months for beta/rc, since we had a longer dev round) May 1st - release 8.4, open 8.5 dev June 1st - first 8.5 commitfest (we don't worry about short May because we have built up patche queue) July - second round of dev August - second/final commitfest Sept - beta opens October - rc opens November - release 8.5, open 8.6 December - first commitfest for 8.6 Jan 2010 - second dev cycle Feb - final commitfest March - 8.6 beta April - 8.6 rc May 2010 - release 8.6 -- 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] 8.4 release planning
Robert Treat writes: > Now I am starting to think that we cannot prevent large patches from showing > up at the end of a cycle no matter what, and the only way to really "solve" > that problem is to lesson the pain of getting bumped from a release. Ie. > instead of being bump meaning you must wait 12-14 months till next release, > we move toward more of a 6 month cycle of development. I really can't see going in that direction. In the first place, no one wants to spend a third or more of the time in beta mode. In the second place, if the problem is big patches that take a long time to develop, halving the length of the development cycle is no solution. (If it did work, our plea to break large patches into segments landing in different commitfests would have had more results.) In the third place, unless we get an upgrade-in-place process that works all the time, we would be looking at maintaining twice as many back branches in order to provide the same kind of release lifespan we have today. We are at the limit of what we can realistically do in back-branch maintenance already :-( 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] 8.4 release planning
On Tue, 27 Jan 2009, Chad Sellers wrote: I'll speak to this a bit (Josh is also a Tresys employee). I can't say who my customers are, but I can speak to their needs. They really need row-level mandatory access controls (so both). From the perspective of what this would buy as far as this feature being a PostgreSQL advocacy point, one of the questions Tom asked about a bit upthread is still a bit hazy here. There are commercial database offerings selling into the "trusted" space already. While the use-cases you describe make perfect sense, I don't think it's clear to everyone yet if there's a unique draw to a PostgreSQL + selinux solution that the class of customers you're talking about would prefer it to purchasing one of those products. Is the cost savings the main driver here, or is there something else about a secure LAPP stack that makes it particularly compelling? -- * Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD -- 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] 8.4 release planning
Robert Treat writes: > On Tuesday 27 January 2009 10:34:59 Joshua D. Drake wrote: >> We have tried the short release cycle before, it was called 8.2. It >> fails, remarkably. > I think this is a bit of revisionsit history. JD got the release number wrong, it was 8.3, but otherwise there's no revisionism involved: http://archives.postgresql.org/pgsql-hackers/2006-12/msg00786.php The theme that our release cycles are too long is not exactly new, of course, eg http://archives.postgresql.org/pgsql-hackers/2000-05/msg00574.php http://archives.postgresql.org/pgsql-hackers/2001-06/msg00766.php http://archives.postgresql.org/pgsql-hackers/2003-11/msg00889.php but by now I think we've learned to stop banging our heads against that particular rock. One-year major cycles work for this project, shorter ones are wishful thinking. 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] 8.4 release planning
On Tuesday 27 January 2009 18:51:01 Tom Lane wrote: > Robert Treat writes: > > Now I am starting to think that we cannot prevent large patches from > > showing up at the end of a cycle no matter what, and the only way to > > really "solve" that problem is to lesson the pain of getting bumped from > > a release. Ie. instead of being bump meaning you must wait 12-14 months > > till next release, we move toward more of a 6 month cycle of development. > > I really can't see going in that direction. In the first place, no one > wants to spend a third or more of the time in beta mode. Yeah, I was thinking that, but the truth is we do that now. We released last Febuary right? and we're looking at releasing (optimisttically) May 1st, right? So thats 15months, of which November - May (6 months) will have been feature freeze / beta / rc phase of development. > In the > second place, if the problem is big patches that take a long time to > develop, halving the length of the development cycle is no solution. > (If it did work, our plea to break large patches into segments landing > in different commitfests would have had more results.) I think this is a mis-assesment of our problem. The problem is not that big patches take a long time; not so much that they don't, just that is not a problem we can solve... "Hey Simon, code faster!" is not going to work ;-) The problem is that the pain point is extremely high for missing a given release cycle. If you don't make a specific release, you have a 12-14 month wait for feature arrival. Given that choice, someone who deperately need (aka wants) HS/SEPostgres/Win32/HOT/IPU/etc... will likely be willing to push a release 3-6 months for that one feature. Incidentally, this is probably why people didnt worry about making a given commitfest. The pain point was low, so there was no percieved need to rework a patch for a specific commit, since there was another one just a couple months away. However, we still see a rush of patches at the final freeze because people know that "there is no tommorrow" at that point. > In the third > place, unless we get an upgrade-in-place process that works all the > time, we would be looking at maintaining twice as many back branches > in order to provide the same kind of release lifespan we have today. > We are at the limit of what we can realistically do in back-branch > maintenance already :-( > Yeah, I can't argue with that. I'm not sure it's an unsolvable problem though; if odd/even release maintenance doesn't sound good, we could do something like ubuntus LTS, where we pick 1 release every 3 years to make a long-term support commitment (I think 5 years is our current max), and keep other releases on a shorter lifespan (1 or 2 years). Certainly having IPU (or is that UIP?) would make that an easier decision. -- 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] 8.4 release planning
Here is morning now, so I started to follow the discussion now... Stephen Frost wrote: > * Gregory Stark (st...@enterprisedb.com) wrote: >> It does seem weird to simply omit records rather than throw an error and >> require the user to use a where clause, even if it's something like WHERE >> pg_accessible(tab). It was an implementation of very earlier version of SE-PostgreSQL. (Maybe, its revision number was still less than 500.) It rewrites WHERE clause of given queries, but Tom suggested such a query rewrite easily makes a bug and hard to maintain in the future, so I removed the code and put a hook in ExecScan(), which featch a tuple from relation and checks condition. (I think it was a good suggestion. It also enables to reduce the scale of SE-PostgreSQL patches.) Indeed, it requires additional checks and disables a few kind of optimization, when these enhanced-security features are activated. However, I made clear some times that we assume security focused users don't give their first priority on performance. I can understand performance is a significant factor for database management system, so the default of these features are *disabled* unless user explicitly activate them. > It is weird from an SQL perspective, I agree with you there. On the > other hand, it's what the security community is looking for, and is > what's implemented by other databases (Oracle, SQL Server...) that > do row-level security and security labels. Requiring a where clause > or you throw an error would certainly make porting applications that > depend on that mechanism somewhat difficult, and doesn't really seem > like it'd gain you all that much... -- OSS Platform Development Division, NEC KaiGai Kohei -- 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] 8.4 release planning
On Tuesday 27 January 2009 19:04:49 Tom Lane wrote: > Robert Treat writes: > > On Tuesday 27 January 2009 10:34:59 Joshua D. Drake wrote: > >> We have tried the short release cycle before, it was called 8.2. It > >> fails, remarkably. > > > > I think this is a bit of revisionsit history. > > JD got the release number wrong, it was 8.3, but otherwise there's no > revisionism involved: > http://archives.postgresql.org/pgsql-hackers/2006-12/msg00786.php > The revisionism was that of "remarkable failure". That was our shortest release cycle in the modern era. And it didn't have the advantage of the commitfest process. But I think what is important here is to recognize why it didn't work. Once again we ended up with large, complex features (HOT, tsearch) that people didn't want to wait 14 months to see if they missed the 8.3 release. And yes, most of these same arguements were raised then... "full text search is killer feature", "whole applications are waiting for in-core full text search", "hot will give allow existing customers to use postgres on a whole new level", "not fair to push back patches so long when developers followed the rules", "sponsors wont want to pay for features they wont see for years", "developers dont want to wait so long to see features committed", and on and on... The more I think about it, the more I feel that where we failed for 8.3 was not having a short 8.4 cycle lined up, which would give more freedom to bump patches to the next release. > The theme that our release cycles are too long is not exactly new, > of course, eg > http://archives.postgresql.org/pgsql-hackers/2000-05/msg00574.php > http://archives.postgresql.org/pgsql-hackers/2001-06/msg00766.php > http://archives.postgresql.org/pgsql-hackers/2003-11/msg00889.php Yeah, I remember all that, and I think you'll find that I mostly was on the other side of this issue :-) But many of the arguments from back then don't apply any more. Remember when you couldn't depend on pg_dump giving you dumps in the right order? Now that was a recipe for painful upgrades. With things like Slony, it's now possible to upgrade a majority of the Postgres installations with extremely minimal downtime. (And yes, I happen to have one that wont work with slony, but hey...) > but by now I think we've learned to stop banging our heads against > that particular rock. One-year major cycles work for this project, > shorter ones are wishful thinking. > Do they? 1 year cycles certainly don't solve the problem of being left with big/complex left over patches. They don't decrease the amount of time (as a percentage) we spend in freeze/beta/release mode. And we don't even get them out in 1 year; this 1 year cycle looks like at least 15 months. -- 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] 8.4 release planning
Joshua Brindle wrote:
Tom Lane wrote:
Ron Mayer writes:
It seems to me that there are two different standards to which this
feature
might be held.
Is the goal
a) SEPostgres can provide useful rules to add security to some
specific applications so long as you're careful to avoid crafting
policies that produce bizarre behaviors (like avoiding restricing
access to foreign key data you might need). On the other hand it
gives you enough rope to hang yourself and produce weird results
that don't make sense from a SQL standard point of view if you
aren't careful matching the SEPostgres rules with your apps.
or
b) SEPostgreSQL should only give enough rope that you can not
craft rules that produce unexpected behavior from a SQL point
of view; and that it would be bad if one can produce SEPostgres
policies that produce unexpected SQL behavior.
With my other hat on (the red one) what I'm concerned about is whether
this patch will ever produce a feature that I could turn on in the
standard Red Hat/Fedora build of Postgres. Right at the moment it seems
that the potential performance hit, for users who are *not using*
SEPostgres but merely have to use a build in which it is present,
might be bad enough to guarantee that that will never happen.
According to the comments in security/sepgsql/core.c:
/*
* sepgsqlIsEnabled
*
* This function returns the state of SE-PostgreSQL when PGACE hooks
* are invoked, to prevent to call sepgsql() functions when
* SE-PostgreSQL is disabled.
*
* We can config the state of SE-PostgreSQL in $PGDATA/postgresql.conf.
* The GUC option "sepostgresql" can have the following four parameter.
*
* - default: It always follows the in-kernel SELinux state. When it
*works in Enforcing mode, SE-PostgreSQL also works in
*Enforcing mode. Changes of in-kernel state are delivered
*to userspace SE-PostgreSQL soon, and SELinux state
*monitoring process updates it rapidly.
* - enforcing : It always works in Enforcing mode. In-kernel SELinux
*has to be enabled.
* - permissive : It always works in Permissive mode. In-kernel SELinux
*has to be enabled.
* - disabled : It disables SE-PostgreSQL feature. It works as if
*original PostgreSQL
*/
and in the hooks there is a pgace_feature that turns off the checks:
void
pgaceGramAlterRelation(Relation rel, HeapTuple tuple, DefElem *defel)
{
switch (pgace_feature)
{
#ifdef HAVE_SELINUX
case PGACE_FEATURE_SELINUX:
if (sepgsqlIsEnabled())
{
sepgsqlGramAlterRelation(rel, tuple, defel);
return;
}
break;
#endif
default:
break;
}
if (defel)
ereport(ERROR,
(errcode(ERRCODE_PGACE_ERROR),
errmsg("unable to set security
attribute of table "
"via ALTER TABLE")));
}
So the pgace_feature turns off the backend call, there is an extra
function call, and a branch but that shouldn't cause the kind of
performance degradation you are talking about.
This hook is only available when an enhanced security feature is
enabled, so I injected ereport() at the tail.
(It is invoked on ALTER TABLE ... SECURITY_LABEL = '...';)
However, most of hooks do nothing or don't change existing behavior
when enhanced security is disabled.
So, I can't understand why it gives adverse affects in performances.
I can admit it needs additional steps to invoke empty functions at least.
However, using "static inline" was arguable in the previous discussion
due to the GCC dependency.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei
--
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] 8.4 release planning
On 1/27/09 6:57 PM, "Greg Smith" wrote: > On Tue, 27 Jan 2009, Chad Sellers wrote: > >> I'll speak to this a bit (Josh is also a Tresys employee). I can't say who >> my customers are, but I can speak to their needs. They really need row-level >> mandatory access controls (so both). > > From the perspective of what this would buy as far as this feature being a > PostgreSQL advocacy point, one of the questions Tom asked about a bit > upthread is still a bit hazy here. There are commercial database > offerings selling into the "trusted" space already. While the use-cases > you describe make perfect sense, I don't think it's clear to everyone yet > if there's a unique draw to a PostgreSQL + selinux solution that the class > of customers you're talking about would prefer it to purchasing one of > those products. Is the cost savings the main driver here, or is there > something else about a secure LAPP stack that makes it particularly > compelling? > Cost savings may be a driver, but it's certainly not the main driver. A problem with the current systems (e.g. Oracle) is that they largely operate in their own world. Oracle Label Security labels do not extend outside the database to the rest of the system, which makes it impossible to build certain things. For instance, you can't really build a trusted LAPP stack. With SE-PostgreSQL, the label used for access control is bound by the kernel and used by it and the other components of the stack (apache, PostgreSQL). We can even extend all the way to the end system using labeled IPSec. Another major drawback to the currently available trusted databases is that they have hard-coded policy rules rather than flexible ones. While these hard-coded rules may be appropriate in some scenarios, they often end up being impractical. For instance, any sort of pipeline (like that of my example 3) is difficult if not impossible to implement on most of these hard-coded systems. Additionally, changing the label in most of these systems requires a privilege that lets you bypass the policy rules, while a flexible Type Enforcement system (like SE-PostgreSQL) allows you to specify exactly how relabels should be allowed within the policy. I'll be happy to provide more details where required. Hopefully that provided a little light. Thanks, Chad Sellers -- 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] 8.4 release planning
Robert Treat writes: > The more I think about it, the more I feel that where we failed for 8.3 was > not having a short 8.4 cycle lined up, which would give more freedom to bump > patches to the next release. Heh. The reason we wanted a short 8.3 cycle was so we could push out patches that had been held over from 8.2. We are going to have exactly no credibility if we tell Simon et al "we're pushing these patches to 8.5, but don't worry, it'll be a short release cycle". I think the best thing we could do overall is to set release dates and stick to them. If your patch is not ready, well, at least it will get out in a defined amount of time. Right now, the *real* problem with it being pushed to the next release is you don't know how successful some other guy will be at persuading us to delay the next release. 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] 8.4 release planning
On Tue, 2009-01-27 at 21:07 -0500, Tom Lane wrote: > Robert Treat writes: > > The more I think about it, the more I feel that where we failed for 8.3 was > > not having a short 8.4 cycle lined up, which would give more freedom to > > bump > > patches to the next release. > > Heh. The reason we wanted a short 8.3 cycle was so we could push out > patches that had been held over from 8.2. We are going to have exactly > no credibility if we tell Simon et al "we're pushing these patches to > 8.5, but don't worry, it'll be a short release cycle". > > I think the best thing we could do overall is to set release dates and > stick to them. If your patch is not ready, well, at least it will get > out in a defined amount of time. Right now, the *real* problem with it > being pushed to the next release is you don't know how successful some > other guy will be at persuading us to delay the next release. +1 Joshua D. Drake > > regards, tom lane > -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- 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] 8.4 release planning
Andrew Sullivan wrote: On Tue, Jan 27, 2009 at 12:41:36PM -0500, Stephen Frost wrote: * Gregory Stark (st...@enterprisedb.com) wrote: It does seem weird to simply omit records rather than throw an error and require the user to use a where clause, even if it's something like WHERE pg_accessible(tab). […] do row-level security and security labels. Requiring a where clause or you throw an error would certainly make porting applications that depend on that mechanism somewhat difficult, and doesn't really seem like it'd gain you all that much... Throwing an error would entail a side-channel leak that would not be acceptable to the security community, I bet. That said, I have reservations, along the lines of Peter E's, that the early design-level objections to the approach were never answered. I certainly never got any real answer to questions I asked, for what it's worth. I will note that I tried to have a look at the literature on this topic. As I started to read, it became obvious that it was copious, but pretty well-determined. What bothered me most about the answers I got was that there never seemed to be an answer to "please outline the design principles" except for "it's what SE-Linux does". The OS-level control rules seemed to me to be totally foreign to the database world, precisely because ACID is a problem in databases in a way it isn't for filesystems under the traditional UNIX model. I formed the impression -- only an impression, mind, that there was a poor fit between SE-Linux and database systems, and that the proponents had decided that enough caulk (in the form of "don't do that") would seal the gap. As I noted before, there is a symmetrical structure between OS and DBMS. In operating system, a process accesses objects (like file, socket, ...) managed by operating system via system calls. Its security system (filesystem permission, SELinux, ...) acquires the request and applies its access control rules. In DBMS, a client accesses database objects managed by DBMS via SQL queries. Its security system (Database ACL, SE-PostgreSQL, ...) aquires the request and applies its access control rules. We have similar structures everywhere, not only DBMS and OS. What we should pay attention is a subject entity accesses via a method provided by object managers (DBMS, OS, ...), and object managers apply its rules to decide either "allowed" or "denied" on acquired request. I haven't (obviously) been paying much attention to this topic since, but I detect something of the same sort of response in the recent discussion. Maybe the goal isn't explicit enough. If the goal is compliance with some set of well-defined tests, what are they? If the goal is buzzword compliance, what are the tests of that (to the extent there ever are some)? If the goal is just "security enhancement", I confess that I am still unable to understand the definitions of "security" and "enhancement" such that I think we have some operationalization of what the patch is supposed to provide. The most significant feature is centralized access control policy between OS and DBMS. Did you attend PGcon2008? I talked here we should consider the value of information asset is independent from the way to store them. Needless to say, the value of information asset is decided by its contents. If your credit card number is recorded on a paper, do you think it has lesser value than recorded on database? Thus, from the viewpoint of security, we need to consider the way to apply unified centralized access controls. SELinux works as "security server". It enables to provide a centralized access control decision any other object managers (like, Linux kernel, X-window, PostgreSQL, ...). It is quite consistent because of common security policy and common clearance of entities. It finally enables to apply centralized access control policy on whole of application stack. Please note that 95% of attacks in 2008 targeted to web system, so it gives a nightmare for security folks. Thanks, I know there are people who think this is cool. I guess, if I were running the circus, I'd want to know what's cool about it, and why. Then maybe the project would be in a position to understand whether that kind of cool is the way it wants to be. But without a clear problem statement, and a roadmap of how the patches solve the problem, I'm at a loss. And last I checked (which was, admittedly, not today), the project pages didn't have that information. A -- OSS Platform Development Division, NEC KaiGai Kohei -- 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] 8.4 release planning
Tom Lane wrote: > Heh. The reason we wanted a short 8.3 cycle was so we could push out > patches that had been held over from 8.2. We are going to have exactly > no credibility if we tell Simon et al "we're pushing these patches to > 8.5, but don't worry, it'll be a short release cycle". > > I think the best thing we could do overall is to set release dates and > stick to them. On the other hand, we might be better throwing out release dates and releasing at the end of any Commit Fest where there is enough demand/interest. Then we could release 8.4 now, with few objections since people would know that if Hot Standby has enough demand it could be released within one commitfest of it being in good shape. Likewise the SE* guys would be aware that if they want that patch to drive a release, they'd need to round up more visible demand. Heck, 8.4 could have been released a whole commitfest ago if enough people think FSM is the killer feature in that one. -- 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] 8.4 release planning
Tom Lane wrote: > Joshua Brindle writes: >> Tom Lane wrote: >>> Right, which is why it's bad for something like a foreign key constraint >>> to expose the fact that the row does exist after all. > >> Once again, this is not an issue for us. > > Yes it is an issue; claiming it isn't doesn't make it so. You just > stated, in effect, that you don't implement data hiding in the > filesystem because it would break standard Unix filesystem semantics. > How is that consistent with your opinion that it's okay to break > standard SQL semantics in order to implement data hiding in a database? > > The question of whether there is a covert channel is only a small part > of my complaint here. If it's the judgement of security experts that > that's an acceptable thing, that's fine, it's their turf. But SQL > behavior is my turf, and I'm not happy with discarding fundamental > semantic properties. Do you forget a GUC option: sepostgresql_row_leve = on/off ? It was a requirement from Simon Riggs at Oct 2008, IIRC. Its original purpose is to reduce storage consumption due to the security label of each tuples, however, it can allow users to choose the granularity of access controls in finally. I can understand you have a complaint about covert channels via PK/FK due to the row-level granularity. However, in other hand, we can already see a commercial producet which provides row-level access controls without any cares about covert channels. It shows a fact that not negligible number of users accept row-level granularity, even if it has covert channels. What is needed is an explicit documentation about covert channels and providing a few options to users. It is not a reasonable stance to deny anything due to a single item which is acceptable some of people, at least. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei -- 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] 8.4 release planning
Ron Mayer writes: > Tom Lane wrote: >> I think the best thing we could do overall is to set release dates and >> stick to them. > On the other hand, we might be better throwing out release dates > and releasing at the end of any Commit Fest where there is enough > demand/interest. > Then we could release 8.4 now, with few objections since people would > know that if Hot Standby has enough demand it could be released within one > commitfest of it being in good shape. Huh? The people who'd been working with the expectation of completing their patch in the *next* fest would scream loud and long at having the release schedule pulled out from under them. Any development plan with more than a two-month time horizon would turn into a game of schedule russian roulette. The only way this works without having a lot of pissed-off developers is if we actually release a lot more often, which is not going to fly. We don't have the manpower to manage that, and we don't have users that want it, either. (They might like it better if we had a better upgrade-in-place story, but ...) 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] 8.4 release planning
Joshua Brindle wrote:
Stephen Frost wrote:
* Joshua Brindle (met...@manicmethod.com) wrote:
They are separate. If you look at the patches you'll see a pgace
part, this is where the core interfaces to the security backends, and
you'll see a rowacl backend and an sepgsql backend.
Right, guess it wasn't clear to me that the PGACE bits for row-level
access control could be used independently of SELinux (and maybe even on
systems that don't have SELinux..?).
Sure, if you look at pgaceHooks.c you'll see:
It is basically possible to implement something like "PostgreSQL
Label Security" on PGACE framework.
But I don't want to discuss it now, because it surely burst
SE-PostgreSQL until v8.4 beta.
If desired, I'll queue it my todo list next to SE-PostgreSQL...
bool
pgaceExecScan(Scan *scan, Relation rel, TupleTableSlot *slot)
{
/* Hardwired DAC checks */
if (!rowaclExecScan(scan, rel, slot))
return false;
switch (pgace_feature)
{
#ifdef HAVE_SELINUX
case PGACE_FEATURE_SELINUX:
if (sepgsqlIsEnabled())
return sepgsqlExecScan(scan, rel, slot);
break;
#endif
default:
break;
}
return true;
}
Notice the rowacl call outside of the HAVE_SELINUX ifdefs
FYI:
In the earlier version, these are mutually exclusive, so we could
not apply SE-PostgreSQL, when a binary is built with RowAcl feature.
However, Bruce Momjian suggested it is not proper manner in
PostgreSQL, because it intend to wrap all available features
into a single binary due to packaging benefit, and all the
available options should be configured by runtime.
In addition, IIRC, Peter E suggested it is not symmetrical
that we cannot apply both of DAC and MAC on tuples simultaneously,
although SE-PostgreSQL applies MAC on tables/columns which
PostgreSQL has DAC features on.
So, I add a support simultaneous DAC&MAC.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei
--
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] 8.4 release planning
> I think the best thing we could do overall is to set release dates and > stick to them. If your patch is not ready, well, at least it will get > out in a defined amount of time. Right now, the *real* problem with it > being pushed to the next release is you don't know how successful some > other guy will be at persuading us to delay the next release. +1, LOL. Let's not forget that we've already got CTE, window functions, partial vacuums, and column-level permissions, all of which are major features that should benefit a lot of people. I hope Hot Standby gets committed but even if it doesn't, I'm still going to get a lot of benefit out of this release, so I'd like it to happen on some sort of reasonable time scale. ...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] 8.4 release planning
On Tue, Jan 27, 2009 at 2:18 PM, Tom Lane wrote: > > This seems to me to be exactly parallel to deciding that SELinux should > control only table/column permissions within SQL; an approach that would > be enormously less controversial, less expensive, and more reliable than > what SEPostgres tries to do. > seems that the controversial part of sepgsql is row level permissions, can we try to commit (obviously with good revision and test) the table/column privileges part of that patch? that is still a step on the direction of full centralized security management on the system... let the row level privileges part for 8.5, that way the patch will be smaller now and then... remember, postponed is not rejected is just a way to give more time to think (WITH patch comes from the prior release cycle and was committed in this release), not to think about one scenario but about all possible scenarios in a more wide audience -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- 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] 8.4 release planning
On Wed, 28 Jan 2009, KaiGai Kohei wrote: It shows a fact that not negligible number of users accept row-level granularity, even if it has covert channels. From my read of the examples that Chad provided, keeping the existence of things secret from complete outsiders doesn't look like the prime concern. There's plenty of these applications floating around where everyone involved is cleared, but to different levels and projects. The person working on a "secret" project knows perfectly well that there are also "top secret" projects floating around they aren't cleared for, and that's OK. They'll probably detect their existence by the doors they're not allowed through long before they notice that database rows are missing. If you're able to sit in front of a computer that's capable of even reaching this information but aren't supposed to be anywhere near it, that means there's been a physical security breach. Where I suspect this is all is going to settle down into is that if 1) the SE GUC is on and 2) one of the tables in a join has rows filtered, then you can expect that a) it's possible that the result will leak information, which certainly need to be documented, and b) the optimizations Tom mentioned that "assume foreign key constraints hold" will not be possible to implement, so performance will suck compared to a similar situation in an unsecured environment. And all that may very well be just fine as far as the people wanting to build applications with SEPostgreSQL are concerned. It will just hint toward using a schema design with table-level controls instead if you care about high performance on that style of join. -- * Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD -- 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] 8.4 release planning
Tom Lane wrote: > The flaw in that argument is that as you are doing it, the > de-optimization only happens on queries that actually need the behavior. > As the SEPostgres patch is constructed, the planner could *never* trust > an FK for optimization since it would have no way to know whether row > level permissions might be present (perhaps only for some rows) at > execution time. Is the "never" is really correct? In the following case, it is necessary not to apply optimization: - SE-PostgreSQL is working, and its row-level access controls are available (sepostgresql_row_level=on). - Row-level ACL is available on the target relation. It is controlable via table option. So, it is necessary to add a new security hook to give a hint the optimizer. Sorry, I overlooked this optimization. But is is not a fundamental design issue. PGACE already has a hook to give a hint to optimizer. It will be a similar one. See, pgaceAllowFunctionInlined(...); http://code.google.com/p/sepgsql/source/browse/trunk/sepgsql/src/backend/security/pgaceHooks.c#948 Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei -- 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] 8.4 release planning
Jaime Casanova wrote: On Tue, Jan 27, 2009 at 2:18 PM, Tom Lane wrote: This seems to me to be exactly parallel to deciding that SELinux should control only table/column permissions within SQL; an approach that would be enormously less controversial, less expensive, and more reliable than what SEPostgres tries to do. seems that the controversial part of sepgsql is row level permissions, can we try to commit (obviously with good revision and test) the table/column privileges part of that patch? Actually, it is already done. http://code.google.com/p/sepgsql/source/browse/trunk/sepgsql/src/backend/utils/misc/guc.c#1242 http://code.google.com/p/sepgsql/source/browse/trunk/sepgsql/src/backend/security/sepgsql/permissions.c#518 Its original purpose is different, to reduce storage consumption. But it can be a point of compromise. See, http://archives.postgresql.org/message-id/492691a8.8030...@ak.jp.nec.com Is it a reasonable option to allow users to turn on/off? I can add a documentation about its background and tradeoffs, for user's correct decision. Thanks, that is still a step on the direction of full centralized security management on the system... let the row level privileges part for 8.5, that way the patch will be smaller now and then... remember, postponed is not rejected is just a way to give more time to think (WITH patch comes from the prior release cycle and was committed in this release), not to think about one scenario but about all possible scenarios in a more wide audience -- OSS Platform Development Division, NEC KaiGai Kohei -- 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] 8.4 release planning
Greg Smith wrote: Where I suspect this is all is going to settle down into is that if 1) the SE GUC is on and 2) one of the tables in a join has rows filtered, then you can expect that a) it's possible that the result will leak information, which certainly need to be documented, and b) the optimizations Tom mentioned that "assume foreign key constraints hold" will not be possible to implement, so performance will suck compared to a similar situation in an unsecured environment. c) security feature gives the optimizer a hint "don't optimize out this table, please!" via a security hook. I think it is a quite reasonable approach, as I noted in another message. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei -- 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] 8.4 release planning
On Tuesday 27 January 2009 21:07:48 Tom Lane wrote: > Robert Treat writes: > > The more I think about it, the more I feel that where we failed for 8.3 > > was not having a short 8.4 cycle lined up, which would give more freedom > > to bump patches to the next release. > > Heh. The reason we wanted a short 8.3 cycle was so we could push out > patches that had been held over from 8.2. And the reason that didn't work was because when we got to feature freeze, we once again had several large, complex patches which people didn't want to push for the long 8.4 cycle. (But note: people are willing to push patches when they believe the wait time won't be excessive for eventual inclusion) > We are going to have exactly > no credibility if we tell Simon et al "we're pushing these patches to > 8.5, but don't worry, it'll be a short release cycle". > The other options being we stall 8.4 indefinatly waiting for HS (which, honestly I am comfortable with), or his patches get pushed and he doesnt get them for another 14 months. Seems to me our credibility isn't really even a factor here. Right now I'm really trying to figure out how to solve this problem for the long term. If we say up front now that the next 2 cycles are short cycles, then I think people will be more willing to push patches come end-of-8.5 (and let's not pretend we're not going to have this same argument over streaming replication or synchronous replay or merge command or whatever hot feature is almost ready at that time) > I think the best thing we could do overall is to set release dates and > stick to them. If your patch is not ready, well, at least it will get > out in a defined amount of time. Right now, the *real* problem with it > being pushed to the next release is you don't know how successful some > other guy will be at persuading us to delay the next release. > I wont argue that setting release dates and sticking to them is a bad idea, but that extra month at the end that that occures due to feature lobbying doesn't strike me as the straw breaking the camels back, it's the 12-14 months in front of that people don't want to wait through. -- 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] 8.4 release planning
Greg Smith wrote: > Where I suspect this is all is going to settle down into is that if 1) > the SE GUC is on and 2) one of the tables in a join has rows filtered, > then you can expect that a) it's possible that the result will leak > information, which certainly need to be documented, As far as I can tell this is the case however you hide the information. If you implemented it with views you'll have the same issue. If you hide the existence of project p_id="TOPSECRET01" and people can run inserts then they can spot it. Likewise, it you have fkey references to the row then deletions can be used to spot it. -- Richard Huxton Archonet Ltd -- 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] 8.4 release planning
Greg Smith wrote: PostgreSQL advocacy point, one of the questions Tom asked about a bit upthread is still a bit hazy here. There are commercial database offerings selling into the "trusted" space already. While the use-cases you describe make perfect sense, I don't think it's clear to everyone yet if there's a unique draw to a PostgreSQL + selinux solution that the class of customers you're talking about would prefer it to purchasing one of those products. Is the cost savings the main driver here, or is there something else about a secure LAPP stack that makes it particularly compelling? According to the data available to me, it is a combination of doing it better than the other guys (e.g., a SELinux type interface instead of something handcrafted) and the usual cost savings. -- 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] 8.4 release planning
Richard Huxton wrote: Greg Smith wrote: Where I suspect this is all is going to settle down into is that if 1) the SE GUC is on and 2) one of the tables in a join has rows filtered, then you can expect that a) it's possible that the result will leak information, which certainly need to be documented, As far as I can tell this is the case however you hide the information. If you implemented it with views you'll have the same issue. If you hide the existence of project p_id="TOPSECRET01" and people can run inserts then they can spot it. Likewise, it you have fkey references to the row then deletions can be used to spot it. It is a covert channel discussion. At least, SE-PostgreSQL does not care about hiding its existence, so it does not prevent user to infer the existence of a tuple with same key value, using PK confliction. (Please note that he must have a info about PK value or lucky to make a key confliction.) But, it enables to prevent unclassified user to read the tuple, and him to know an info the tuple contains "p_id=TOPSECRET01" as a result of this read action. Thanks, -- KaiGai Kohei -- 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] 8.4 release planning
On Wed, Jan 28, 2009 at 4:28 AM, Peter Eisentraut wrote: > Greg Smith wrote: > >> PostgreSQL advocacy point, one of the questions Tom asked about a bit >> upthread is still a bit hazy here. There are commercial database offerings >> selling into the "trusted" space already. While the use-cases you describe >> make perfect sense, I don't think it's clear to everyone yet if there's a >> unique draw to a PostgreSQL + selinux solution that the class of customers >> you're talking about would prefer it to purchasing one of those products. >> Is the cost savings the main driver here, or is there something else about >> a secure LAPP stack that makes it particularly compelling? >> > > According to the data available to me, it is a combination of doing it > better than the other guys (e.g., a SELinux type interface instead of > something handcrafted) and the usual cost savings. > I don't know about better, but I would definitely say that it's a more integrated (with the OS) solution. Can you get Oracle to use SELinux policies? Sure. But it would take a combination of Label Security, Fine Grained Access Control tweaks, custom C functions, and custom policies to handle the access control. And, it would cost a helluva lot of money. In short, this would make Postgres quite a bit more appetizing to those who need this functionality, those who prefer SELinux-based policies, and those who don't have the time/money to do it in systems like Oracle. How many people is that? Based on my consulting experience and questions from DoD/DoE people specifically, I think the number of people needing this feature is fairly small right now. But, it wouldn't hurt us to have it. Just to make it clear, this feature wouldn't make Postgres a "trusted" database in any certification sense. So, using that term would likely cause confusion and get people who used it thinking it had an EAL certification into trouble. -- Jonah H. Harris, Senior DBA myYearbook.com
Re: [HACKERS] 8.4 release planning
Robert Treat wrote: > The problem is that the pain point is extremely high for missing a given > release cycle. If you don't make a specific release, you have a 12-14 month > wait for feature arrival. Given that choice, someone who deperately need (aka > wants) HS/SEPostgres/Win32/HOT/IPU/etc... will likely be willing to push a > release 3-6 months for that one feature. There will always be some features that people are willing to push a release for, if it's a feature they want. At least I hope so - because that means we keep adding new features that people want. But as long as there is some overlap in development timelines - which there will *always* be - there will always be some patch that is not quite ready on time. If the release is pushed back, maybe some other patch could also have been finished by the new deadline - should that also be included? What about a completely new feature that isn't even started yet, but that could easily be finished before the new deadline? What makes those less worthy? The question is, how long do we make people wait for *other* features. It delays this version *and* the next. > Incidentally, this is probably why people didnt worry about making a given > commitfest. The pain point was low, so there was no percieved need to rework > a patch for a specific commit, since there was another one just a couple > months away. However, we still see a rush of patches at the final freeze > because people know that "there is no tommorrow" at that point. A problem at this point is that we are basically serializing the project over one or a couple of patches. All those people who aren't qualified to review/work on HS or SEPG are left in a position where they can't get anything done. Sure, they can work on patches offline, and add them to a hypothetical future commitfest that they have no clue when it's going to happen, so they don't know when they need to be available to deal with feedback. And we're back to ending up with a lot of conflicting patches simply because they sit in the queue for too long. That's a lot of developer talent wasted. The commitfests were designed in part to get around this - to get developers quick feedback so they can get on with more features. The final commitfest being much longer than the others by design already makes this hard. Dragging it out even longer makes it an even bigger failure in this way. We can't just say that everybody should help with these patches. Not everybody is qualified to do so, or has an interest to, while they're still both qualified and interested in working on other things for 8.5. >> In the third >> place, unless we get an upgrade-in-place process that works all the >> time, we would be looking at maintaining twice as many back branches >> in order to provide the same kind of release lifespan we have today. >> We are at the limit of what we can realistically do in back-branch >> maintenance already :-( >> > > Yeah, I can't argue with that. I'm not sure it's an unsolvable problem > though; > if odd/even release maintenance doesn't sound good, we could do something > like ubuntus LTS, where we pick 1 release every 3 years to make a long-term > support commitment (I think 5 years is our current max), and keep other > releases on a shorter lifespan (1 or 2 years). Certainly having IPU (or is > that UIP?) would make that an easier decision. We're still going to have to pay the full cost of doing a release every time. With beta/rc management, release notes, announcements, postings, packaging and all those things. The PostgreSQL tree tends to be a lot more stable than others. In many cases, you can just snapshot CVS HEAD and get more or less the same things. Perhaps if someone were to simply maintain a bunch of tags or branches against "known feature-points in the system" in a separate SCM somewhere that'd be enough for people who desperately need the features - or who just want to test them out earlier. That would be close to zero cost for the core project to maintain. //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] 8.4 release planning
Josh Berkus wrote: > >> That's modest. I've talked to several oracle and db2 shops that want a >> standby for reporting that has relatively easy setup/maintenance >> (handling ddl is a big part of this) and the HS feature your working >> on will give them something as good as what they are getting now. So >> yeah, HS appeals to future users as well. > > I've talked to some of my clients, and while they *want* synch or > near-synch HS, even slow HS is useful to them *now*. > > One client is planning on deploying a rather complex FS cloning > infrastructure just to have a bunch of reporting, testing and read-only > search databases they need. They'd be thrilled with an HS feature which > produced DBs which were an hour out of date (or even 6 hours out of > date), but ran read-only queries. I have a lot of clients who would be thrilled to have stuff that's been in our tree for half a year by now, and they'd be thrilled to have it *now*. How much extra should we have them wait for the needs of your clients? (Yes, I have clients now who would very much like HS as well, of course, but that's not the point) //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] 8.4 release planning
Robert Haas wrote: >> I think the best thing we could do overall is to set release dates and >> stick to them. If your patch is not ready, well, at least it will get >> out in a defined amount of time. Right now, the *real* problem with it >> being pushed to the next release is you don't know how successful some >> other guy will be at persuading us to delay the next release. > > +1, LOL. > > Let's not forget that we've already got CTE, window functions, partial > vacuums, and column-level permissions, all of which are major features > that should benefit a lot of people. I hope Hot Standby gets > committed but even if it doesn't, I'm still going to get a lot of > benefit out of this release, so I'd like it to happen on some sort of > reasonable time scale. Agreed. Even without HS, this will be one of the biggest releases we've had in a while, IMHO. //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] 8.4 release planning
Magnus Hagander writes: > Josh Berkus wrote: >> >> One client is planning on deploying a rather complex FS cloning >> infrastructure just to have a bunch of reporting, testing and read-only >> search databases they need. They'd be thrilled with an HS feature which >> produced DBs which were an hour out of date (or even 6 hours out of >> date), but ran read-only queries. > > I have a lot of clients who would be thrilled to have stuff that's been > in our tree for half a year by now, and they'd be thrilled to have it > *now*. How much extra should we have them wait for the needs of your > clients? I really am unconvinced by the argument that delaying existing features is a big deal. Logically it's less of a big deal than delaying HS a whole release cycle which I already said I think isn't a big deal either. This is purely a question of latency between development and release; we still get just as much in each release, it's just 6-12 months later than it might have been. What bothers me is delaying work on things like Bitmap Indexes which won't really start in earnest until Gianni can get feedback from the lists after the release. Or Join Removal which Simon isn't going to look at until after HS is committed (not *released* -- once it's *committed* he'll be free to go on to other things). This would impact *bandwidth* of development which I think is a much bigger deal. It reduces the amount of new features in each release, not just which release they fall in. I'm a bit shocked by how long Tom expects the release cycle to take even if we froze the code today. I guess I forget how long it takes and how many steps there are from past releases. If it's going to be 9+ months between Nov 1st and the first commitfest I'm worried about how many patches will be languishing in the queue with their authors having moved on to other more fruitful pastures in the mean time. If we delay further we're talking about close to a year with developers left hanging. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- 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] 8.4 release planning
On Wed, Jan 28, 2009 at 11:31:25AM +0900, KaiGai Kohei wrote: > As I noted before, there is a symmetrical structure between > OS and DBMS. Well, you said that before. I think your analogy is awful. I don't think the similarities are nearly as great as you think, and I also think there are significant differences that _make_ the difference in these cases. In particular, > In operating system, a process accesses objects (like file, > socket, ...) managed by operating system via system calls. > Its security system (filesystem permission, SELinux, ...) > acquires the request and applies its access control rules. > > In DBMS, a client accesses database objects managed by DBMS > via SQL queries. Its security system (Database ACL, > SE-PostgreSQL, ...) aquires the request and applies its access > control rules. the difference here is that in the OS, a process accessing the object has few to no guarantees about concurrency. In RDBMS, a very significant reason even to use the DBMS is the ACID guarantees, which make a number of claims about concurrency that simply aren't there in most filesystems. It's at exactly this architectural point that most of the in-principle design questions have been aimed. My personal view is that those questions haven't really been answered very well, but as I've already said I mostly stopped paying attention to this work several months ago; so maybe I overlooked something. I note that Peter and Bruce seem to have been satisfied, so maybe they understood something I don't (that's quite likely). > The most significant feature is centralized access control policy > between OS and DBMS. Right, I get that; but all the discussion I've seen on this suggest that, to get the benefit of the centralised access control, I trade away certain well-understood assumptions of a relational environment, but without much indication that I've done so. > I talked here we should consider the value of information asset > is independent from the way to store them. Yes, I know that was your premise. I am not entirely sure I agree with it, is the thing. > Needless to say, the value of information asset is decided by its > contents. Nonsense. The value of an information asset is determined only partly by its contents. I'd argue that the value of an information asset is a function of its use-value. If the information asset is completely unusable, then it isn't worth anything at all. > If your credit card number is recorded on a paper, > do you think it has lesser value than recorded on database? Yes. The database makes the credit card number available to other applications, which can then use that data to charge the credit card with other purchases. For me, therefore, the piece of paper, correctly handled, imposes less risk than the database; in addition, the piece of paper offers a smaller advantage, because it cannot be leveraged to make other interactions more convenient. Finally, the piece of paper offers a different kind of risk, because if it is mishandled and then becomes the basis on which the number ends up in a database, I have a new problem for which I was not prepared. I believe my fundamental objection was that, as far as I was able to tell, SELinux simply didn't have anything useful to say about concurrent actions on data under SE controls; that's because it was aimed at a fairly primitive database (a filesystem) without the rich concurrency support of RDBMS. I still don't see anywhere in your discussions an extension of the SELinux model to account for that concurrency richness, so I think there's something wrong with the principles from which your're starting. I'm totally prepared to admit I've missed something, however. Also, since this isn't really my problem any more, I'm unlikely to spend much time reading more design notes or anything of the sort. Finally, > It finally enables to apply centralized access control policy on > whole of application stack. > Please note that 95% of attacks in 2008 targeted to web system, > so it gives a nightmare for security folks. this argument gets to the heart of what you seem to want, which is a centralized system that guarantees the controls you want. I'm actually dubious that such centralization is actually the benefit that its proponents seem to think it is; but if it is, then the centralised system needs to be exactly as rich as the richest system under control. By starting with SELinux, I argue that the approach starts with a too-poor model. (See above.) More fundamentally, the premise that the database is just a part of an "application stack" is, in my view, exactly _why_ these systems are so vulnerable to attack. Database management systems are not designed to be dumb storage for a single application, and they're actually very poorly adapted to such a role. My impression is that SEPostgres is an attempt to finally force the database system under such controls, as though it were a glorified filesystem. I hav
Re: [HACKERS] 8.4 release planning
On Wed, 2009-01-28 at 14:55 +0100, Magnus Hagander wrote: > If the release is pushed back, maybe some other patch could also have > been finished by the new deadline - should that also be included? What > about a completely new feature that isn't even started yet, but that > could easily be finished before the new deadline? What makes those less > worthy? Committers have always added features after freeze... For example, Virtual TransactionIds were added to 8.3 almost exactly 5 months after feature freeze. Not even suggested until about 5 months after, in fact. I argued against such a change late in the cycle, but we did it. It's a great feature and I'm glad we did. If we try to shorten the release cycle, we just end up missing out on tuning opportunities that emerge in beta. IIRC 8.2 was delayed while we changed index cost models. Thankfully. 8.0 was shipped with a completely ineffective bgwriter, so the above changes seem like common sense in comparison. The only way to keep the dev window open longer is to overlap the start of the next cycle with the previous one. i.e. branch new version before final release. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- 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] 8.4 release planning
On Wednesday 28 January 2009 08:55:56 Magnus Hagander wrote: > We're still going to have to pay the full cost of doing a release every > time. With beta/rc management, release notes, announcements, postings, > packaging and all those things. > As I pointed out to Tom, by percentage the additional beta/release cycles wouldn't be very different than what we have now; the more churn you have during development, the longer it takes to beta/release. I'm pretty sure that if we had pushed everything not committed on December 1st, we would be very close to release right now, and that's with more dev cycles than I'm talking about for 8.5. And I think most people (aka not the patch authors :-) would have been willing to push the stuff we're dealing with now if they knew the next release would be closer to 6 months than 14 months. -- 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] 8.4 release planning
Robert Treat writes: > On Wednesday 28 January 2009 08:55:56 Magnus Hagander wrote: >> We're still going to have to pay the full cost of doing a release every >> time. With beta/rc management, release notes, announcements, postings, >> packaging and all those things. > As I pointed out to Tom, by percentage the additional beta/release cycles > wouldn't be very different than what we have now; the more churn you have > during development, the longer it takes to beta/release. I don't believe that thesis in itself, because it ignores economies of scale and parallelism for beta testing. And in any case it's complete nonsense in respect to back-branch maintenance costs. If we double the frequency of releases we are going to be pretty much forced to halve the support lifetime, and ain't nobody going to be happy with us. 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] 8.4 release planning
Le 28 janv. 09 à 16:22, Simon Riggs a écrit : The only way to keep the dev window open longer is to overlap the start of the next cycle with the previous one. i.e. branch new version before final release. This is the second time the idea is raised and I like it. Do we have anywhere near enough resources for this to happen? That would mean first 8.5 commit-fest begins e.g. April 1st, while hopefully 8.4 enters beta or get ready for it. If no commiter is available for reviewed patch they just get postponed as ready to commit on next commit fest. This way our Round Robin Reviewers team is still at work while in beta, and more importantly developpers still get feedback. -- dim -- 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] 8.4 release planning
Dimitri Fontaine writes: > Le 28 janv. 09 à 16:22, Simon Riggs a écrit : >> The only way to keep the dev window open longer is to overlap the >> start of the next cycle with the previous one. i.e. branch new version >> before final release. > This is the second time the idea is raised and I like it. > Do we have anywhere near enough resources for this to happen? No. The key committers are overstressed already. It would also pretty much guarantee that we get *no* help during review and beta, because everyone else will find it more interesting/fun to work on new patches instead. The current system at least gives non-committer developers some motivation to help with that stuff, because they know their patches won't be looked at until beta is over. 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] 8.4 release planning
Zdenek Kotala wrote: > > Bruce Momjian p??e v po 26. 01. 2009 v 23:02 -0500: > > OK, time for me to chime in. > > > > I think the outstanding commit-fest items can be broken down into four > > sections: > > > > o Log streaming > > o Hot standby > > o SE-PostgreSQL > > o Others > > You omit pg_upgrade. Does it mean that this project is already killed > for 8.4? I considered pg_upgrade one of the "others" on the list; it is not as complex as the previous three. -- Bruce Momjian 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
