On Thu, Oct 15, 2009 at 10:40 PM, Ron Mayer <rm...@cheapcomplexdevices.com> wrote: > Dave Page wrote: >> I never said it wasn't - in fact I said from the outset it was about >> box-checking, and that anyone doing things properly will use >> LDAP/SSPI/Kerberos etc. > > I don't understand why the box-checkers can't already check that > box; with the explanation stating "Yes - by using LDAP or GSSAPI > or PAM configured accordingly". > > Or do checkbox-lists specifically say > "can postgres do XYZ with all OS security features disabled".
Well I guess that's possible, but what I hear our SEs complaining about is having to justify features that require additional software or features that other DBMSs offer natively. Let me offer a couple of examples: Q. Does the product offer password policy enforcement? Oracle: Yes SQL Server: Yes PostgreSQL: Yes (using an external authentication provider with policy enforcement). Q. Does the product support external authentication providers? Oracle: Yes SQL Server: Yes PostgreSQL: Yes Q. Does the product offer transparent data encryption? Oracle: Yes SQL Server: Yes PostgreSQL: Yes (using an encrypted filesystem). Q. Does the product offer audit capabilities? Oracle: Yes SQL Server: Yes PostgreSQL: Yes (must be manually implemented using triggers and functions) Too many of those caveats, and it's easy to see how we can be discounted early in the evaluation phase. It's not helped that often these lists will be drawn up by people used to working with the commercial DBMSs, so we probably wouldn't get extra points for having a dozen procedural languages, or other features that are largely unique to PostgreSQL, no matter how cool and useful they are. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
