Re: [HACKERS] About the CREATE TABLE LIKE indexes vs constraints issue
Jeff Davis wrote: ... Honestly, I've never used LIKE in a table definition aside from one-off design experiments. For that kind of thing, what I want is to just get everything (except perhaps FKs if the above situation applies), and I adjust it from there. Are there people out there who use LIKE in their production schema files? I for one never have either. If I needed such a thing I'd go through the steps of using pg_dump to get the structure, edit the result to get my new table's name and structure, and then use that SQL to create the table and add it to the CVS so I would have a record of it if I ever needed to refer to it later (when did I do this?) or if I needed to recreate the scheme because of a crash or whatever. Too easy to make new table with LIKE and not have the proper record of how to recreate the changes, IMHO. (Of course you could capture the SQL w/ history and use that.) Greg W. -- 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] PATCH: Spurious 22 in hstore.sgml
Bruce Momjian wrote: David Fetter wrote: On Thu, Dec 17, 2009 at 11:01:19AM +0100, Albe Laurenz wrote: Magnus Hagander wrote: On Wed, Dec 16, 2009 at 20:34, David E. Wheeler wrote: *** a/doc/src/sgml/hstore.sgml --- b/doc/src/sgml/hstore.sgml Heh, interesting. That clearly shouldn't be there. Applied. Does this count as catch-22? Patch-22, perhaps? Wait, that 22 was holding up the entire database system. ;-) You mean holding it up as in that was a load bearing integer! or holding it up as in this is a small caliber firearm -- gimme yer schema! ? Greg W. -- 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] SE-PgSQL patch review
KaiGai Kohei wrote: === Joshua D. Drake wrote: On Tue, 2009-12-01 at 14:46 -0500, Tom Lane wrote: Joshua D. Drake j...@commandprompt.com writes: On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote: This is totally separate from the really important question of whether SE-Linux has a future, and another about whether, if SE-Linux has a future, PostgreSQL needs to go there. Why would we think that it doesn't? Have you noticed anyone except Red Hat taking it seriously? I just did a little research and it appears the other two big names in this world (Novel and Ubuntu) are using something called App Armor. As far as I can see, SUSE, Ubuntu and Debian provide SELinux option. But they are more conservative than RedHat/Fedora, because it is not enabled in the default installation. I don't think it is unpreferable decision. Users can choose the option by themself according to requirements in the system. === How much of the work currently at hand might be applicable to other security models ? Would this be useful groundwork for anyone who wanted to implement other frameworks in terms of hooks, cleanup of existing code, etc. ? Greg W. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- 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] SE-PostgreSQL Specifications
KaiGai -- I was pulled away from any work on this for a few days ... what can I do to help, if anything ? (Keeping in mind that my knowledge of the internals of postgres is, alas, minimal.) ... I had a quick look at this new page and want to take another, more careful, look. The sheer scope of this proposal undoubtedly gives pause to many, so I'd urge a certain minimalism at first to prove that the concept works and doesn't damage the core functionality at all when it is not used (fairly straight forward). Eventually rough measures of the performance hit when it is used will be useful, but users will expect something of a slow-down, I suspect, in exchange foe the greater security. To that end, I am wondering if there is test data yet designed ? Are there prescribed tests (I remember seeing some but they seem to be buried in months/threads that I have not yet re-dicsovered) ? I have some experience doing QA and could perhaps also help in these, a little. And let me add, I am in awe of your efforts on this ! G - Original Message From: KaiGai Kohei kai...@ak.jp.nec.com To: Stephen Frost sfr...@snowman.net Cc: KaiGai Kohei kai...@kaigai.gr.jp; Robert Haas robertmh...@gmail.com; pgsql-hackers@postgresql.org; Greg Williamson gwilliamso...@yahoo.com; Sam Mason s...@samason.me.uk; Joshua Brindle met...@manicmethod.com Sent: Monday, August 3, 2009 12:09:45 AM Subject: Re: [HACKERS] SE-PostgreSQL Specifications Stephen Frost wrote: I think what I should do on the next is ... - To check up whether it is really possible to implement SELinux's model. - To describe the list of the security functions in the new abstraction layer. - To discuss the list of permission at: http://wiki.postgresql.org/wiki/SEPostgreSQL_Development#Mandatory_access_controls That sounds like a good approach. As we define the security functions to go into the abstraction layer, I would also say we should identify the exact pieces of existing code which are going to move. I began to describe the list of abstraction layer functions (but not completed yet): http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction In my current impression, it indeed requires a few kilo lines of changes, but it is not impossible scale. I now plans to submit two patches for the next commit fest. The one is implementation of the abstraction layer. The other is basic implementation of the SE-PostgreSQL. So, I would like to fix external specification at least. The specifications for developer notes definitions of permissions: http://wiki.postgresql.org/wiki/SEPostgreSQL_Development As Robert suggested before, I plans to support access controls on the following database objects and permissions at the first stage. * databases * schemas * tables * columns * sequences * functions * tablespaces Do you have any comment for the directions? Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- 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] SE-PostgreSQL Specifications
Thanks for the updates. I might suggest a couple of small changes: a) a section that explains comments like This is not supported in the initial version -- do you mean in the first Beta release of SE-PostgreSQL, or not in the initial release(s) for commitfests ? If it is not supported why mention it ? If experienced users of SELinux expect it, they might look for an explanation as to why it is missing and when it might appear. I'm not sure if postgres DB hackers would care if is it is not to be included. How much do these compromise the design, and if so, are there specific plans for implementing them ? b) something which explains the differences between SELinux and SEPostgreSQL on the one hand (for SE fans). You've done a good job of outlining the differences and similarities with the more standard ACL methods and that needs to be kept prominent so people with DB experience can see the differences. I am all in favor of external links if you can find good explanation of concepts elsewhere. This is a very high level outline and so I'd be tempted to move all implementation details to another page -- basically everything from Installation on, with the exception of the overview of the dump issues, is (to my eye) a detail that doesn't need exposing (yet). I'll send mail when I have a few paragraphs done so you can check it and see if you approve. Apologies for top-posting -- lame mailer. Greg W. - Original Message From: KaiGai Kohei kai...@ak.jp.nec.com To: KaiGai Kohei kai...@kaigai.gr.jp Cc: Sam Mason s...@samason.me.uk; pgsql-hackers@postgresql.org Sent: Monday, July 27, 2009 11:57:32 PM Subject: Re: [HACKERS] SE-PostgreSQL Specifications I revised the SE-PostgreSQL Specifications: http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft - Put several external link to introduce something too detail for PostgreSQL documentations. - Paid attention not to use undefined terminology, such as security context, security policy and mandatory access controls. - Revised whole of the composition in the Brief overview section. - Put an example of security policy rule. - SECURITY_LABEL option was replaced by SECURITY_CONTEXT to avoid meaningless confusion. I believe it become better than previous revision. Thanks, KaiGai Kohei wrote: Sam Mason wrote: On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote: Indeed, the draft used the term of security context with minimum introductions, but not enough friendliness for database folks. The purpose of security context is an identifier of any subject and object to describe them in the security policy. Because the security policy is common for operating system, databases, x-window and others, any managed database objects needs its security context. Anyway, I need to introduce them in the security model section. I'm coming to the conclusion that you really need to link to external material here; there must be good (and canonical) definitions of these things outside and because SE-PG isn't self contained I really think you need to link to them. This will be somewhat of a break from normal PG documentation because so far everything has been self contained, it's chosen its own interpretation of the SQL standard and it needs to document that. SE-PG will be interacting with much more code from outside and showing which parts of these are PG specific vs. which parts are common to all SELinux seems important. If you try to document *everything* you're going to be writing for years and give the impression that everything is implemented in SE-PG. A dividing line needs to be drawn between what is PG specific and what is SELinux (why not SEL?). It also seems to me reasonable suggestion. However, a reasonable amount (which should be adjusted under discussions) of description should be self-contained. For example, security context is a formatted short string is not enough to understand why it is necessary and what is the purpose. As Robert suggested, a few example and definition of technical terms will help database folks to understand what it is, even if self-contained explanation is not comprehensive from viewpoint of security folks. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- 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] SE-PostgreSQL Specifications
[wretched top-posting -- begs forgiveness!]
KaiGai --
I have edited the first three sections (up to but not including
Architecture), mostly cleaning up language but I did run into a few places
where I am not sure if I got the proper meaning -- I flagged those in square
brackets (e.g.[...]) and with your name. Feel free to change them, accept them,
or confer back with me about them.
In particular, in the Security policy section you had:
TE rules use the third field in the security context. It is called type or
domain (for processes).
allow httpd_t sepgsql_ro_table_t : db_table {getattr select lock};
I thought that colons were used to split these fields, so the above line would
have only 2 ? Perhaps after the httpd_t ?
I'd like to get some feedback from you (and any other readers) before I do more
... I need to go deal an invasion of the kitchen -- it is garbage collection
morning (early) and I just had a pretty young skunk and two raccoon kits in
rapid order and I have to clean up and secure the premises.
Regards!
G
- Original Message
From: Greg Williamson gwilliamso...@yahoo.com
To: KaiGai Kohei kai...@ak.jp.nec.com; KaiGai Kohei kai...@kaigai.gr.jp
Cc: Sam Mason s...@samason.me.uk; pgsql-hackers@postgresql.org
Sent: Tuesday, July 28, 2009 1:20:29 AM
Subject: Re: [HACKERS] SE-PostgreSQL Specifications
Thanks for the updates.
I might suggest a couple of small changes:
a) a section that explains comments like This is not supported in the initial
version -- do you
mean in the first Beta release of SE-PostgreSQL, or not in the initial
release(s) for commitfests ?
If it is not supported why mention it ? If experienced users of SELinux expect
it, they might look for
an explanation as to why it is missing and when it might appear. I'm not sure
if postgres DB
hackers would care if is it is not to be included. How much do these compromise
the design,
and if so, are there specific plans for implementing them ?
b) something which explains the differences between SELinux and SEPostgreSQL on
the one
hand (for SE fans). You've done a good job of outlining the differences and
similarities with the
more standard ACL methods and that needs to be kept prominent so people with DB
experience
can see the differences.
I am all in favor of external links if you can find good explanation of
concepts elsewhere. This is a
very high level outline and so I'd be tempted to move all implementation
details to another page --
basically everything from Installation on, with the exception of the
overview of the dump issues,
is (to my eye) a detail that doesn't need exposing (yet).
I'll send mail when I have a few paragraphs done so you can check it and see if
you approve.
Apologies for top-posting -- lame mailer.
Greg W.
- Original Message
From: KaiGai Kohei kai...@ak.jp.nec.com
To: KaiGai Kohei kai...@kaigai.gr.jp
Cc: Sam Mason s...@samason.me.uk; pgsql-hackers@postgresql.org
Sent: Monday, July 27, 2009 11:57:32 PM
Subject: Re: [HACKERS] SE-PostgreSQL Specifications
I revised the SE-PostgreSQL Specifications:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
- Put several external link to introduce something too detail
for PostgreSQL documentations.
- Paid attention not to use undefined terminology, such as
security context, security policy and mandatory access
controls.
- Revised whole of the composition in the Brief overview section.
- Put an example of security policy rule.
- SECURITY_LABEL option was replaced by SECURITY_CONTEXT to
avoid meaningless confusion.
I believe it become better than previous revision.
Thanks,
KaiGai Kohei wrote:
Sam Mason wrote:
On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote:
Indeed, the draft used the term of security context with minimum
introductions, but not enough friendliness for database folks.
The purpose of security context is an identifier of any subject and
object to describe them in the security policy. Because the security
policy is common for operating system, databases, x-window and others,
any managed database objects needs its security context.
Anyway, I need to introduce them in the security model section.
I'm coming to the conclusion that you really need to link to external
material here; there must be good (and canonical) definitions of these
things outside and because SE-PG isn't self contained I really think you
need to link to them.
This will be somewhat of a break from normal PG documentation because
so far everything has been self contained, it's chosen its own
interpretation of the SQL standard and it needs to document that. SE-PG
will be interacting with much more code from outside and showing which
parts of these are PG specific vs. which parts are common to all SELinux
seems important.
If you try to document *everything* you're going to be writing for years
and give the impression that everything is implemented in SE-PG. A
dividing line needs
Re: [HACKERS] SE-PostgreSQL Specifications
KaiGai -- I have a few suggestions which I will post in a bit, and some rather extensive edits of the existing Wiki, mostly for syntax rather than content. How do you want the latter ? I can email them offline as text, or you could set me up with a login on the wiki and I could do them in place (perhaps paragraph by paragraph) ? Thanks, and apologies for the delay ! Greg W. ps most of what I have is orthogonal to the lively discussions since Friday. -- 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] SE-PostgreSQL Specifications
Excellent ... I'll try to have something tomorrow (Friday PDT) but I've got some non-work related issues which may keep from giving this a good look until the weekend (FWIW). I'll post any questions I have. Thanks, Greg W. - Original Message From: KaiGai Kohei kai...@ak.jp.nec.com To: Robert Haas robertmh...@gmail.com Cc: pgsql-hackers@postgresql.org; KaiGai Kohei kai...@kaigai.gr.jp; Greg Williamson gwilliamso...@yahoo.com; Sam Mason s...@samason.me.uk; Joshua Brindle met...@manicmethod.com Sent: Thursday, July 23, 2009 9:54:10 PM Subject: SE-PostgreSQL Specifications Here is the initial draft of SE-PostgreSQL specifications: http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft I've described it from the scratch again with paying attention for the people knowing nothing about SELinux. In some points, it uses comparison between the database privilege mechanism and SE-PostgreSQL for easy understanding. Please point out, if ... - Its composition can be improved. - Here is not enough introductions for what user wants to know. - Here is too much explanations, more brief one will be available. - Here is not easy understandable for database folks. - Here is not enough English quality. - And so on... In addition, I would like to fix its specifications during the discussion. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.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] [PATCH] SE-PgSQL/tiny rev.2193
KaiGai Kohei asked: ... Here is one idea. I'll upload the draft of the documentation on the wikipage shorter than the current one. Is somebody available to check it from the viewpoint of native English user or database users? I'll give a shot ... native english speaker, some experience with documentation, and I'm fond of postgres, but not really deserving of being on this alias (not a hacker in the useful sense of the word). Greg Williamson -- 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] SE-PostgreSQL?
David Fetter asked: 1. Among the committers who could maintain the features, whatever they turn out to be, who is actually volunteering to do so? I am not a committer, but I saw a message about issues with documentation -- I would be willing to help on making documentation and comments more robust; I don't speak Japanese but have a couple of friends who do that I can call upon for some help. 2. Apart from Kohei-san and Stephen Frost, is anybody actually interested in having this feature at all? This feature would be of interest in some corporate circles as well as government and health care. That said it seems like two issues are biting those working on it: (a) it's a lot of work even to get a simple version and (b) the model differs from the more tradition ACL and trying to wrap collective heads around the implications is an exercise in and of itself. My gut feeling is this is so much work that it needs a paying sponsor to see it through. Trying to do it without more hands is likely to distract from other items on the to-do list. Greg W. -- 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] Maintenance Policy?
Andrew Dunstan wrote: ... branch | released | curr_version | curr_date | final_date ++--++ 8.4| 2009-07-01 | 8.4.0| 2009-07-01 | 8.3| 2008-02-04 | 8.3.7| 2009-03-16 | 8.2| 2006-12-05 | 8.2.13 | 2009-03-16 | 8.1| 2005-11-08 | 8.1.17 | 2009-03-16 | 8.0| 2005-01-19 | 8.0.21 | 2009-03-16 | 7.4| 2003-11-17 | 7.4.25 | 2009-03-16 | 2009-09-01 (projected) 7.3| 2002-11-27 | 7.3.21 | 2008-01-07 | 2008-01-07 7.2| 2002-02-04 | 7.2.8| 2005-05-09 | 2005-05-09 7.1| 2001-04-13 | 7.1.3| 2001-08-15 | 2001-08-15 7.0| 2000-05-08 | 7.0.3| 2000-11-11 | 2000-11-11 Yeah, nice. I was thinking of a press release when we EOL a branch as well. You may want to indicate the dead-end of the 8.1 Windows variant as well. http://www.postgresql.org/download/windows says Only PostgreSQL 8.2 and above are supported on Windows. ... might prevent confusion. Greg Williamson -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
