Re: [HACKERS] Design Considerations for New Authentication Methods
* Henry B. Hotz ([EMAIL PROTECTED]) wrote: I've been looking at adding SASL or GSSAPI as an auth method. I have some questions about how to handle the flow of control changes. Great! I'd love to see that implemented, personally, so if you're looking for help, please let me know. Thank you. I will! ;-) Do you know Java? I'm doing this ultimately because I want the JDBC driver to support encrypted connections with Kerberos and without needing SSL. As an added plus a Windows-native client should support it. Interesting, I thought you were going for the authentication only. What's the real gain in doing Kerberos encryption over SSL encryption? Doesn't Java come with SSL support anyway these days? My main hesitation between SASL and GSSAPI is that the Windows equivalent APIs for SASL have not received the same degree of interoperability testing as SSPI--GSSAPI. I don't have a published example to crib from. For general information the relevant calls are at the bottom of http://msdn.microsoft.com/library/default.asp?url=/ library/en-us/secauthn/security/authentication_functions.asp. One reason for this could be that they appear to be available only on server platforms, and not on cilents, if you look at the documentation. That said, I have the DLL file and the export functions on my XP machine, so it's definitly present there - I'm unsure if it *works* or is supported. My registry does indicate that I have the GSSAPI profile for SASL, which would be an indication that it should. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [GENERAL] Index greater than 8k
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Nov 01, 2006 at 07:16:37PM -0300, Alvaro Herrera wrote: [EMAIL PROTECTED] wrote: [...] a functional trigram index? (this would be very cool). Heh :-) I meant an index, using the pg_trgm opclass (which indexes trigrams; hence the trigram part), on a function that would extract the text from a bytea column [...] [goes back to cave, tests...] Wow, that works: CREATE INDEX i2 ON words USING gist(lower(word) gist_trgm_ops); so I can interpose a (of course immutable) function before gist/trigram does its thing. Why didn't I dare to assume that this will work? Thanks for the hint. - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFScGvBcgs9XrR2kYRAl9tAJ9JvWvVo0nrexs409IIKPustuJkXwCbBW5n W5/wwTogiSdg3rhTXq5pRio= =t90X -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [SQL] Case Preservation disregarding case
On Wed, 2006-11-01 at 11:31 -0500, Chuck McDevitt wrote: But, stepping back from all that, what is it the users want? 1) When re-creating a CREATE TABLE statement from whatever catalog info, they'd like the names to come back exactly as then entered them. If I do: CREATE TABLE BobsTable (WeeklySales numeric(10,2), SomeStrangeName int); They'd like to see exactly that when the CREATE TABLE gets re-created, not what we do now: CREATE TABLE bobstable (weeklysales numeric(10,2), SomeStrangeName int); This would be very good indEEd. It can be very annoying trying to locate a table when the user swears they called it one thing and actually the case or quotation is different. Current behaviour isn't useful, even if it is onspec (or is that OnSpec?). Would be better to make this behaviour a userset switchable between the exactly compliant and the more intuitive. We have namespaces to differentiate between two sources of object names, so anybody who creates a schema where MyColumn is not the same thing as myColumn is not following sensible rules for conceptual distance. It's certainly an error of best practice, even if its not actually a bug. 2) When doing reports, they'd like the name as entered to be the title of the column: Select * from bobstable; Would be nice if they saw this: WeeklySalesSomeStrangeName ------ ... Producing ?column? or somesuch to use in the report, it could return a title like sum(WeeklySales) That would be just great. I'm not sure the spec says what the titles should be, does it? -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [PATCHES] Writing WAL for relcache invalidation:pg_internal.init
On Wed, 2006-11-01 at 12:05 -0500, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: Enclose a patch for new WAL records for relcache invalidation. I don't think this works. RelationCacheInitFileInvalidate is executed post-commit, which means that there's a window between commit and where you propose to write the WAL entry. A crash and restart in that interval would leave the catalog changes committed, but not reflected into pg_internal.init. Surely you are pointing out a bug, no? If a backend did crash, the init file would be wrong and we'd get exactly the same wrong relfilenode errors we got after that PITR. The issue must surely be that the patch isn't wrong per se, just that RelationCacheInitFileInvalidate is called too late and that requires an additional fix. Are we certain that a crash between commit and invalidation will cause a PANIC that takes down the server? Doesn't look like its in a critical section to me. I think we're probably better off to just forcibly remove the init file during post-recovery cleanup. The easiest place to do this might be BuildFlatFiles, which has to scan pg_database anyway ... I can do this - I don't have a problem there, but the above issue just occurred to me so I wonder now if its the right thing to do. PITR will be always-safe but normal operation might not be. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Encoding problem
Hi. I have some encoding problems. 1.) Expression of output of log of server http://inet.winpg.jp/~saito/pg_bug/postgresql-2006-11-02_192633.log This is not in the output for the translation by GetText and is ..Native.. message. (Japanese windows--Shift_jis message) 2.) The message makes a mistake when the log is brought with admin-pack. 2006-11-02 19:28:53 ERROR: invalid byte sequence for encoding EUC_JP: 0x938c (SERVER_ENCODING TO EUC_JP) I think that I should solve it about this problem both. However, I have not had for that free time yet The situation is reported for the time being. Various suggestions are welcomed. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Writing WAL for relcache invalidation:pg_internal.init
Tom, Simon et al; Please clarify. PostgreSQL 8.1.5 on sparc-sun-solaris2.9, compiled by GCC gcc (GCC) 3.4.2 We're getting ready to init a new warm standby instance based on last night's snapshot of running prod server. I see a few of these pg_internal.init files in the cluster as it's being unpacked. Same warm standby instance may sit for weeks gobbling up WALs from the prod server then be finally brought live. Question; Is it safe to delete the .init files now (before starting recovery), or perhaps unconditionally right after going live? In other words, is there any sure fire preventative measure that I can apply to guarantee against the fault that started this threadd? Tom wrote: Meanwhile, if you're trying to recover from a PITR backup and it's not working, try removing any pg_internal.init files you can find. Comment above seems to suggest not touching existing pg_internal.init files unless a problem is seen. Thanks Simon Riggs [EMAIL PROTECTED] writes: On Wed, 2006-11-01 at 12:05 -0500, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: Enclose a patch for new WAL records for relcache invalidation. I don't think this works. RelationCacheInitFileInvalidate is executed post-commit, which means that there's a window between commit and where you propose to write the WAL entry. A crash and restart in that interval would leave the catalog changes committed, but not reflected into pg_internal.init. Surely you are pointing out a bug, no? If a backend did crash, the init file would be wrong and we'd get exactly the same wrong relfilenode errors we got after that PITR. The issue must surely be that the patch isn't wrong per se, just that RelationCacheInitFileInvalidate is called too late and that requires an additional fix. Are we certain that a crash between commit and invalidation will cause a PANIC that takes down the server? Doesn't look like its in a critical section to me. I think we're probably better off to just forcibly remove the init file during post-recovery cleanup. The easiest place to do this might be BuildFlatFiles, which has to scan pg_database anyway ... I can do this - I don't have a problem there, but the above issue just occurred to me so I wonder now if its the right thing to do. PITR will be always-safe but normal operation might not be. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- --- Jerry Sievers 305 854-3001 (home) WWW ECommerce Consultant 305 321-1144 (mobilehttp://www.JerrySievers.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] Writing WAL for relcacheinvalidation:pg_internal.init
On Thu, 2006-11-02 at 09:36 -0500, Jerry Sievers wrote: Is it safe to delete the .init files now (before starting recovery), or perhaps unconditionally right after going live? You're safe to delete those files from the restored version of your base backup prior to commencing startup with a recovery.conf. When they are missing they will be recreated automatically. When we agree on how to fix it, which should be soon, I would imagine that the fix can be back patched to 8.0 and 8.1 and fixed prior to release in 8.2. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] Writing WAL for relcache invalidation:pg_internal.init
Simon Riggs [EMAIL PROTECTED] writes: On Wed, 2006-11-01 at 12:05 -0500, Tom Lane wrote: I don't think this works. Surely you are pointing out a bug, no? If a backend did crash, the init file would be wrong and we'd get exactly the same wrong relfilenode errors we got after that PITR. Yeah, which is the same bug we've got now. They're both WAL-replay- doesn't-fix-the-init-file cases. The issue must surely be that the patch isn't wrong per se, just that RelationCacheInitFileInvalidate is called too late and that requires an additional fix. No. In the non-crash situation there is sufficient interlocking to avoid a problem, and I feel no desire to redesign that mechanism. Trying to do it before commit would create its own issues, anyway: someone could install a new init file before you finish committing. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] Writing WAL for relcache invalidation:pg_internal.init
Jerry Sievers [EMAIL PROTECTED] writes: Is it safe to delete the .init files now (before starting recovery), Should be OK as far as I can see. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [SQL] Case Preservation disregarding case
Simon Riggs [EMAIL PROTECTED] writes: We have namespaces to differentiate between two sources of object names, so anybody who creates a schema where MyColumn is not the same thing as myColumn is not following sensible rules for conceptual distance. I'd agree that that is not a good design practice, but the fact remains that they *are* different per spec. Would be better to make this behaviour a userset switchable between the exactly compliant and the more intuitive. That's certainly not happening --- if you make any changes in the semantics of equality of type name, it would have to be frozen no later than initdb time, for exactly the same reasons we freeze locale then (hint: index ordering). regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Tsearch2 index size
I am running versions 8.1.2 and I installed 8.2B last week. I dumped the data from a rather large (several million records) from the old into the new version. My two observations are as follows... Also, keep in mind these are truly just observations, I didn't use any benchmarking tools. If someone can point me to a link of performance tools, I'd be happy to try them and report back! 1. The release notes indicate more efficient vacuuming. However, both vacuums seems to take about the same amount of time, ie. approx: 9 hours. Does more efficient simply mean, less IO/CPU busyness? This one doesn't really bother me, the next one does... Here are my vacuum parms, I used the same ones for both versions, of course. -- maintenance_work_mem = 40 # Unnecessarily high, I know I left it # for comparison's sake. vacuum_cost_delay = 50 vacuum_cost_page_hit = 1 vacuum_cost_page_miss = 10 vacuum_cost_page_dirty = 20 vacuum_cost_limit = 2000 -- 2. I have a tsearch2 index which is 756MB in size in 8.1.2 but balloons to 910MB in 8.2! These numbers were taken right after a REINDEX. Normally, I wouldn't care about physical index size, but this particular index is sitting on a ramdisk, so size really does matter. I see that the tsearch2 type was diddled with in 8.2. Is this an intentional change to improve the tsearch2 performance? Thank you for advice or abuse you give. No. Wait. No abuse please. Richard Whidden ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Design Considerations for New Authentication Methods
On Nov 2, 2006, at 1:18 AM, Magnus Hagander wrote: * Henry B. Hotz ([EMAIL PROTECTED]) wrote: I've been looking at adding SASL or GSSAPI as an auth method. I have some questions about how to handle the flow of control changes. Great! I'd love to see that implemented, personally, so if you're looking for help, please let me know. Thank you. I will! ;-) Do you know Java? I'm doing this ultimately because I want the JDBC driver to support encrypted connections with Kerberos and without needing SSL. As an added plus a Windows-native client should support it. Interesting, I thought you were going for the authentication only. What's the real gain in doing Kerberos encryption over SSL encryption? Doesn't Java come with SSL support anyway these days? My main hesitation between SASL and GSSAPI is that the Windows equivalent APIs for SASL have not received the same degree of interoperability testing as SSPI--GSSAPI. I don't have a published example to crib from. For general information the relevant calls are at the bottom of http://msdn.microsoft.com/library/default.asp?url=/ library/en-us/secauthn/security/authentication_functions.asp. One reason for this could be that they appear to be available only on server platforms, and not on cilents, if you look at the documentation. That said, I have the DLL file and the export functions on my XP machine, so it's definitly present there - I'm unsure if it *works* or is supported. My registry does indicate that I have the GSSAPI profile for SASL, which would be an indication that it should. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Tsearch2 index size
On Mon, 2006-10-23 at 13:36 -0500, [EMAIL PROTECTED] wrote: 2. I have a tsearch2 index which is 756MB in size in 8.1.2 but balloons to 910MB in 8.2! These numbers were taken right after a REINDEX. Normally, I wouldn't care about physical index size, but this particular index is sitting on a ramdisk, so size really does matter. I see that the tsearch2 type was diddled with in 8.2. Is this an intentional change to improve the tsearch2 performance? This might be due to the new FILLFACTOR feature in 8.2. This parameter defaults to 90. If you set it to 100, then you should get similar results as in 8.1. I don't know much about the new GIN indexing, but from what I've read I would expect the index to actually be smaller. Regards, Jeff Davis ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Coding style question
I've noticed a trend in the PostgreSQL code base - for some reason, we tend to avoid initializing automatic variables (actually, the code base is pretty mixed on this point).
For example in _bt_check_unique() we have:
static TransactionId
_bt_check_unique(Relation rel, IndexTuple itup, Relation heapRel,
Buffer buf, ScanKey itup_scankey)
{
TupleDesc itupdesc = RelationGetDescr(rel);
int natts = rel-rd_rel-relnatts;
OffsetNumber offset,
maxoff;
Page page;
BTPageOpaque opaque;
Buffer nbuf = InvalidBuffer;
page = BufferGetPage(buf);
opaque = (BTPageOpaque) PageGetSpecialPointer(page);
maxoff = PageGetMaxOffsetNumber(page);
offset = _bt_binsrch(rel, buf, natts, itup_scankey, false);
...
Notice that four variables are not initialized; instead we assign values to them immediately after declaring them.
I would probably write that as:
static TransactionId
_bt_check_unique(Relation rel, IndexTuple itup, Relation heapRel,
Buffer buf, ScanKey itup_scankey)
{
TupleDesc itupdesc = RelationGetDescr(rel);
int natts = rel-rd_rel-relnatts;
Page page = BufferGetPage(buf);
OffsetNumber maxoff = PageGetMaxOffsetNumber(page);
BTPageOpaque opaque = (BTPageOpaque) PageGetSpecialPointer(page);
OffsetNumber offset = _bt_binsrch(rel, buf, natts, itup_scankey, false);
Buffer nbuf = InvalidBuffer;
...
I'm not trying to be pedantic (it just comes naturally), but is there some reason that the first form would be better? I know that there is no difference in the resulting code, so this is purely a style/maintainability question.
I guess the first form let's you intersperse comments (which is good).
On the other hand, the second form makes it easy to see which variables are un-initialized. The second form also prevents you from adding any code between declaring the variable and assigning a value to it (which is good in complicated code; you might introduce a reference to an unitialized variable).
Just curious.
-- Korry
Re: [HACKERS] Design Considerations for New Authentication Methods
Sorry about the premature send. On Nov 2, 2006, at 1:18 AM, Magnus Hagander wrote: * Henry B. Hotz ([EMAIL PROTECTED]) wrote: I've been looking at adding SASL or GSSAPI as an auth method. I have some questions about how to handle the flow of control changes. Great! I'd love to see that implemented, personally, so if you're looking for help, please let me know. Thank you. I will! ;-) Do you know Java? I'm doing this ultimately because I want the JDBC driver to support encrypted connections with Kerberos and without needing SSL. As an added plus a Windows-native client should support it. Interesting, I thought you were going for the authentication only. What's the real gain in doing Kerberos encryption over SSL encryption? Doesn't Java come with SSL support anyway these days? Well, unless you have an unusually good PKI infrastructure, SSL doesn't provide any cryptographic connection between the client identity and the data received by the server. (At least that's true for the way it's used by Web browsers, I haven't looked at what PG has now.) Likewise a client can be fooled into trusting a spoof, if multiple CA's are trusted. It all depends on the policy enforcement rules you implement, and your control of the cert's. In my case I have good control over the Kerberos infrastructure, but none over the Federal PKI infrastructure. I also want the data channel encryption tied to the client identity so I don't have to worry about Man In The Middle attacks. SASL supports Kerberos, of course, but it's actually technology neutral. You can configure it to be as strong or weak as you want. You could e.g. support the SASL_PLAIN mechanism without requiring an encrypted tunnel, and you would sent passwords in the clear. (Not recommended of course.) SSL fans may want to use the SASL_EXTERNAL mechanism, which picks up the client identity from the SSL tunnel it's running in, or from the OS if it's a machine-local connection. (LDAP servers do the latter.) In my case I want the GSSAPI/Kerberos5 mechanism. These days Java comes with SASL, GSSAPI (via GAAS), and SSL/TLS support. Neither Java, nor Windows support the specific MIT Kerberos API functions used by PostgreSQL. This is largely because MIT itself has been encouraging people to use the standardized GSSAPI and SASL functions instead. The bad thing about these APIs is that they push you an abstraction layer or two away from the Kerberos functionality, which makes them a touch harder to learn and use. My main hesitation between SASL and GSSAPI is that the Windows equivalent APIs for SASL have not received the same degree of interoperability testing as SSPI--GSSAPI. I don't have a published example to crib from. For general information the relevant calls are at the bottom of http://msdn.microsoft.com/library/default.asp?url=/ library/en-us/secauthn/security/authentication_functions.asp. One reason for this could be that they appear to be available only on server platforms, and not on cilents, if you look at the documentation. That said, I have the DLL file and the export functions on my XP machine, so it's definitly present there - I'm unsure if it *works* or is supported. My registry does indicate that I have the GSSAPI profile for SASL, which would be an indication that it should. Since those functions are there to support email clients, I would expect them to be widely available (at least on any machine that has an email client installed). Likewise I would expect them to be functional when talking to e.g. sendmail or postfix servers compiled with the Cyrus SASL library. Since I would use the same SASL library for the server side of the implementation, they're pretty likely to work to some degree. //Magnus I guess this discussion makes it sound like I've convinced myself to use SASL. I still need to resolve how to do name translation. PostgreSQL wants a single unix-like name, and I haven't looked at how to properly do that translation from SASL (or GSSAPI) names. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Coding style question
Shouldn't we turn on warnings by the compiler on uninitialized
variables? This can also be helpful.
--Imad
www.EnterpriseDB.com
On 11/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I've noticed a trend in the PostgreSQL code base - for some reason, we tend
to avoid initializing automatic variables (actually, the code base is pretty
mixed on this point).
For example in _bt_check_unique() we have:
static TransactionId
_bt_check_unique(Relation rel, IndexTuple itup, Relation heapRel,
Buffer buf, ScanKey itup_scankey)
{
TupleDescitupdesc = RelationGetDescr(rel);
int natts = rel-rd_rel-relnatts;
OffsetNumber offset,
maxoff;
Page page;
BTPageOpaque opaque;
Buffer nbuf = InvalidBuffer;
page = BufferGetPage(buf);
opaque = (BTPageOpaque) PageGetSpecialPointer(page);
maxoff = PageGetMaxOffsetNumber(page);
offset = _bt_binsrch(rel, buf, natts, itup_scankey, false);
...
Notice that four variables are not initialized; instead we assign values to
them immediately after declaring them.
I would probably write that as:
static TransactionId
_bt_check_unique(Relation rel, IndexTuple itup, Relation heapRel,
Buffer buf, ScanKey itup_scankey)
{
TupleDescitupdesc = RelationGetDescr(rel);
int natts= rel-rd_rel-relnatts;
Page page = BufferGetPage(buf);
OffsetNumber maxoff = PageGetMaxOffsetNumber(page);
BTPageOpaque opaque = (BTPageOpaque) PageGetSpecialPointer(page);
OffsetNumber offset = _bt_binsrch(rel, buf, natts, itup_scankey,
false);
Buffer nbuf = InvalidBuffer;
...
I'm not trying to be pedantic (it just comes naturally), but is there some
reason that the first form would be better? I know that there is no
difference in the resulting code, so this is purely a style/maintainability
question.
I guess the first form let's you intersperse comments (which is good).
On the other hand, the second form makes it easy to see which variables are
un-initialized. The second form also prevents you from adding any code
between declaring the variable and assigning a value to it (which is good in
complicated code; you might introduce a reference to an unitialized
variable).
Just curious.
-- Korry
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [HACKERS] Coding style question
[EMAIL PROTECTED] writes:
I would probably write that as:
static TransactionId
_bt_check_unique(Relation rel, IndexTuple itup, Relation heapRel,
Buffer buf, ScanKey itup_scankey)
{
TupleDescitupdesc = RelationGetDescr(rel);
int natts= rel-rd_rel-relnatts;
Page page = BufferGetPage(buf);
OffsetNumber maxoff = PageGetMaxOffsetNumber(page);
BTPageOpaque opaque = (BTPageOpaque) PageGetSpecialPointer(page);
OffsetNumber offset = _bt_binsrch(rel, buf, natts, itup_scankey, false);
Buffer nbuf = InvalidBuffer;
The disadvantage of using initializers is that you end up contorting the code
to allow you to squeeze things into the initializers and it limits what you
can do later to the code without undoing them.
For example, if later you find out you have to, say, lock a table before the
itupdesc initializer then all of the sudden you have to rip out all the
initializers and rewrite them as assignments after the statement acquiring the
table lock.
I admit to a certain affinity to lisp-style programming and that does lead to
me tending to try to use initializers doing lots of work in expressions. But I
find I usually end up undoing them before I'm finished because I need to
include a statement or because too much work needs to be done with one
variable before some other variable can be initialized.
But including complex expensive function calls in initializers will probably
only confuse people trying to follow the logic of the code. Including
_bt_binsrch() as an initializer for example hides the bulk of the work this
function does.
People expect initializers to be simple expressions, macro calls, accessor
functions, and so on. Not to call out to complex functions that implement key
bits of the function behaviour.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [HACKERS] Coding style question
On Thu, 2006-11-02 at 23:53 +0500, imad wrote: Shouldn't we turn on warnings by the compiler on uninitialized variables? This can also be helpful. Those warnings should already be enabled, at least with GCC. -Neil ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Design Considerations for New Authentication Methods
On Thu, Nov 02, 2006 at 10:45:24AM -0800, Henry B. Hotz wrote: Well, unless you have an unusually good PKI infrastructure, SSL doesn't provide any cryptographic connection between the client identity and the data received by the server. (At least that's true for the way it's used by Web browsers, I haven't looked at what PG has now.) Likewise a client can be fooled into trusting a spoof, if multiple CA's are trusted. It all depends on the policy enforcement rules you implement, and your control of the cert's. In postgresql the client and server can specify what certificates thay'll accept, there are no default trusted CAs. You can require the client to have a certain certificate, for example. The client can also verify the server has the expected certificate. How much it's used I don't know, but SSL does support it. In my case I have good control over the Kerberos infrastructure, but none over the Federal PKI infrastructure. I also want the data channel encryption tied to the client identity so I don't have to worry about Man In The Middle attacks. The encryption of a channel has nothing to do with verifying the client/server is who they say they are. They can be configured independantly. You can block Man-in-the-middle attacks without encrypting the channel, though it is unusual. I guess this discussion makes it sound like I've convinced myself to use SASL. I still need to resolve how to do name translation. PostgreSQL wants a single unix-like name, and I haven't looked at how to properly do that translation from SASL (or GSSAPI) names. Usually a field in the certificate is the username postgresql wants, which can be mapped via a table. For SASL I don't know. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] Coding style question
Gregory Stark wrote:
[EMAIL PROTECTED] writes:
I would probably write that as:
static TransactionId
_bt_check_unique(Relation rel, IndexTuple itup, Relation heapRel,
Buffer buf, ScanKey itup_scankey)
{
TupleDescitupdesc = RelationGetDescr(rel);
int natts= rel-rd_rel-relnatts;
Page page = BufferGetPage(buf);
OffsetNumber maxoff = PageGetMaxOffsetNumber(page);
BTPageOpaque opaque = (BTPageOpaque) PageGetSpecialPointer(page);
OffsetNumber offset = _bt_binsrch(rel, buf, natts, itup_scankey, false);
Buffer nbuf = InvalidBuffer;
The disadvantage of using initializers is that you end up contorting the code
to allow you to squeeze things into the initializers and it limits what you
can do later to the code without undoing them.
True. And in any case, we tend not to be terrribly anal about style
preferences, especially if they are not documented.
I am sure I have done lots of things in ways other people would not
dream of, and I have certainly seen code done in a style I would never use.
This is a not atypical situation for open source projects, unlike
commercial situations where it is easier to enforce a corporate style.
cheers
andrew
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [HACKERS] Coding style question
On 11/2/06, Gregory Stark [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
I would probably write that as:
static TransactionId
_bt_check_unique(Relation rel, IndexTuple itup, Relation heapRel,
Buffer buf, ScanKey itup_scankey)
{
TupleDescitupdesc = RelationGetDescr(rel);
int natts= rel-rd_rel-relnatts;
Page page = BufferGetPage(buf);
OffsetNumber maxoff = PageGetMaxOffsetNumber(page);
BTPageOpaque opaque = (BTPageOpaque) PageGetSpecialPointer(page);
OffsetNumber offset = _bt_binsrch(rel, buf, natts, itup_scankey, false);
Buffer nbuf = InvalidBuffer;
The disadvantage of using initializers is that you end up contorting the code
to allow you to squeeze things into the initializers and it limits what you
can do later to the code without undoing them.
For example, if later you find out you have to, say, lock a table before the
itupdesc initializer then all of the sudden you have to rip out all the
initializers and rewrite them as assignments after the statement acquiring the
table lock.
Well, its about the coding style. And I doubt there exists a data type
which may not have
an initializer. A NULL / Zero is an option in all cases and you can do
whatever you want to assign it a value immediately after the
initialization section. My two cents!
--Imad
www.EnterpriseDB.com
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Coding style question
Gregory Stark [EMAIL PROTECTED] writes: People expect initializers to be simple expressions, macro calls, accessor functions, and so on. Not to call out to complex functions that implement key bits of the function behaviour. Yeah, I agree with that. But as Andrew noted, we don't really have any hard and fast coding rules --- the only guideline is to do your best to make your code readable, because other people *will* have to read it. In the particular example here I find Korry's proposed coding less readable than what's there, but I can't entirely put my finger on why. Maybe it's just the knowledge that it's less easily modifiable. In general, I'd say initializers with side effects or nonobvious ordering dependencies are definitely bad style, because someone might innocently rearrange them, eg to group all the variables of the same datatype together. You can get away with ordering dependencies like TupleDescitupdesc = RelationGetDescr(rel); int natts = itupdesc-natts; because the dependency is obvious (even to the compiler). Anything more complex than this, I'd write as a statement not an initializer. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Coding style question
The disadvantage of using initializers is that you end up contorting the code
to allow you to squeeze things into the initializers and it limits what you
can do later to the code without undoing them.
For example, if later you find out you have to, say, lock a table before the
itupdesc initializer then all of the sudden you have to rip out all the
initializers and rewrite them as assignments after the statement acquiring the
table lock.
Good point (and I can't argue with your example). But, I think initializers also force you to declare variables in the scope where they are needed. Instead of declaring every variable at the start of the function, it's better to declare them as nested as practical (not as nested as possible, but as nested as practical). That means, you might write the code like this:
static TransactionId
_bt_check_unique(Relation rel, IndexTuple itup, Relation heapRel,
Buffer buf, ScanKey itup_scankey)
{
if( lockTable( ... ))
{
TupleDesc itupdesc = RelationGetDescr(rel);
int natts = rel-rd_rel-relnatts;
Page page = BufferGetPage(buf);
OffsetNumber maxoff = PageGetMaxOffsetNumber(page);
...
The biggest advantage to that style of coding is that you know when each variable goes out of scope. If you declare every variable at the start of the function (and you don't initialize it), it can be very difficult to tell at which points in the code the variable holds a (meaningful) value. If you declare local variables in nested scopes, you know that the variable disappears as soon as you see the closing '}'.
I admit to a certain affinity to lisp-style programming and that does lead to
me tending to try to use initializers doing lots of work in expressions. But I
find I usually end up undoing them before I'm finished because I need to
include a statement or because too much work needs to be done with one
variable before some other variable can be initialized.
But including complex expensive function calls in initializers will probably
only confuse people trying to follow the logic of the code. Including
_bt_binsrch() as an initializer for example hides the bulk of the work this
function does.
People expect initializers to be simple expressions, macro calls, accessor
functions, and so on. Not to call out to complex functions that implement key
bits of the function behaviour.
Agreed - you can certainly take initialization way too far, I just think we don't take it far enough in many cases and I'm wondering if there's some advantage that I'm not aware of.
-- Korry
Re: [HACKERS] Coding style question
Shouldn't we turn on warnings by the compiler on uninitialized variables? This can also be helpful. Those warnings should already be enabled, at least with GCC. Yes, the compiler can detect unitialized variables, But, that introduces a new problem. There are a lot of tools out there (like GCC) that can find unitialized variables (or more specifically, variables which are used before initialization). I've seen too many less-scarred developers add an = NULL to quiet down the tool. But that's (arguably) worse than leaving the variable uninitialized - if you simply initialize a variable to a known (but not correct) value, you've disabled the tool; it can't help you find improperly initialized variables anymore. The variable has a value, but you still don't know at which point in time it has a correct value. That's another reason I prefer initializers (and nested variable declarations) - I can put off creating the variable until I can assign a meaningful value to it. (I don't go so far as to introduce artificial scopes just for the sake of nesting variable declarations). Too many scars... -- Korry
Re: [HACKERS] Coding style question
imad [EMAIL PROTECTED] writes:
Well, its about the coding style. And I doubt there exists a data type
which may not have
an initializer. A NULL / Zero is an option in all cases and you can do
whatever you want to assign it a value immediately after the
initialization section. My two cents!
Actually, there are a lot of situations where putting an initializer is
definitely *bad* style in my opinion, because it can hide errors of
omission that the compiler would otherwise find for you. The most
common example you'll see in the Postgres code is variables that should
be set in each branch of an if or switch construct:
int val;
switch (foo)
{
case A:
val = 42;
break;
case B:
val = 52;
break;
...
default:
elog(ERROR, ...);
val = 0; /* keep compiler quiet */
break;
}
return val;
Someone might think it better to initialize val to 0 and get rid of the
useless (unreachable) assignment in the default case, but I say not.
With this structure, you'll get an uninitialized-variable warning if
you forget to set val in any one of the cases of the switch. That's
a check worth having, especially if the code is at all complicated
within the cases.
When the variable is going to be set anyway in straight-line code at the
top of the function, then it's mostly a matter of taste whether you set
it with an initializer or an assignment. But whenever there are
multiple places that might need to set it, I try to structure the code
to exploit the compiler's ability to catch uninitialized variables,
and that means not using an initializer.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] Coding style question
Yeah, I agree with that. But as Andrew noted, we don't really have any hard and fast coding rules --- the only guideline is to do your best to make your code readable, because other people *will* have to read it. I'm not really looking for hard/fast rules. Just picking brains. In the particular example here I find Korry's proposed coding less readable than what's there, but I can't entirely put my finger on why. Maybe it's just the knowledge that it's less easily modifiable. In general, I'd say initializers with side effects or nonobvious ordering dependencies are definitely bad style, because someone might innocently rearrange them, eg to group all the variables of the same datatype together. You can get away with ordering dependencies like TupleDescitupdesc = RelationGetDescr(rel); int natts = itupdesc-natts; because the dependency is obvious (even to the compiler). Anything more complex than this, I'd write as a statement not an initializer. Agreed - I contrived an example (I just happened to be reading _bt_check_unique()). In fact, I would not initialize 'offset' as I suggested, but I probably would initialize just about everything else. (In fact, in the actual code, there's a code-comment that describes the initialization of offset - I would certainly leave that in place). -- Korry
Re: [HACKERS] Design Considerations for New Authentication Methods
On Nov 2, 2006, at 11:04 AM, Martijn van Oosterhout wrote: On Thu, Nov 02, 2006 at 10:45:24AM -0800, Henry B. Hotz wrote: In my case I have good control over the Kerberos infrastructure, but none over the Federal PKI infrastructure. I also want the data channel encryption tied to the client identity so I don't have to worry about Man In The Middle attacks. The encryption of a channel has nothing to do with verifying the client/server is who they say they are. They can be configured independantly. You can block Man-in-the-middle attacks without encrypting the channel, though it is unusual. Not actually true, at least not in a provable, general sense. There is no way to know that the other end of an encrypted channel is connected where you want it unless you have done some kind of client/ server mutual authentication as part of establishing the channel. TLS does (or can do) this. If PostgreSQL can pick up e.g. the UID from the client cert, then this is a very secure setup. Cudos! (Now if only TLS had something better than RFC 2712 to integrate with Kerberos.) You can do a client/server mutual auth exchange without later encrypting the channel, but then there is nothing to prevent someone from later doing a TCP hijack. This is what the current Kerberos support does. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Coding style question
[EMAIL PROTECTED] writes: initializers also force you to declare variables in the scope where they are needed. Instead of declaring every variable at the start of the function, it's better to declare them as nested as practical (not as nested as possible, but as nested as practical). I agree that in many places it'd be better style to declare variables in smaller scopes ... but that's not the point you started the thread with. In any case, the initializer-vs-assignment decision is the same no matter what scope you're talking about --- I don't see how that forces you to do it either way. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Coding style question
On 11/3/06, Tom Lane [EMAIL PROTECTED] wrote:
imad [EMAIL PROTECTED] writes:
Well, its about the coding style. And I doubt there exists a data type
which may not have
an initializer. A NULL / Zero is an option in all cases and you can do
whatever you want to assign it a value immediately after the
initialization section. My two cents!
Actually, there are a lot of situations where putting an initializer is
definitely *bad* style in my opinion, because it can hide errors of
omission that the compiler would otherwise find for you. The most
common example you'll see in the Postgres code is variables that should
be set in each branch of an if or switch construct:
int val;
switch (foo)
{
case A:
val = 42;
break;
case B:
val = 52;
break;
...
default:
elog(ERROR, ...);
val = 0; /* keep compiler quiet */
break;
}
return val;
Someone might think it better to initialize val to 0 and get rid of the
useless (unreachable) assignment in the default case, but I say not.
With this structure, you'll get an uninitialized-variable warning if
you forget to set val in any one of the cases of the switch. That's
a check worth having, especially if the code is at all complicated
within the cases.
When the variable is going to be set anyway in straight-line code at the
top of the function, then it's mostly a matter of taste whether you set
it with an initializer or an assignment. But whenever there are
multiple places that might need to set it, I try to structure the code
to exploit the compiler's ability to catch uninitialized variables,
and that means not using an initializer.
regards, tom lane
Thats right!
The next thing is that, should this be left out on the compiler? I
mean, there may still be some scenarios where compiler won't be able
to help us. For instance, passing an uninitialized variable to a
function by reference.
Regards
--Imad
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Coding style question
On Thu, 2006-11-02 at 14:23 -0500, [EMAIL PROTECTED] wrote: Yes, the compiler can detect unitialized variables, In most situations, anyway. I've seen too many less-scarred developers add an = NULL to quiet down the tool. But that's (arguably) worse than leaving the variable uninitialized - if you simply initialize a variable to a known (but not correct) value, you've disabled the tool; it can't help you find improperly initialized variables anymore. I definitely agree that this is not good style[1] -- if you see any Postgres code that does this, I think it should be fixed. (This is probably something you could teach a compiler to warn you about, as well.) That's another reason I prefer initializers (and nested variable declarations) - I can put off creating the variable until I can assign a meaningful value to it. Well, clearly you should only assign meaningful values to variables, but I don't see anything wrong with omitting an initializer, initializing the variable before using it, and letting the compiler warn you if you forget to do this correctly. I agree with Greg's rationale on when to include an initializer in a variable declaration (when the initializer is trivial: e.g. casting a void * to a more specific pointer type, or using one of the PG_GETARG_XXX() macros in a UDF). (I don't go so far as to introduce artificial scopes just for the sake of nesting variable declarations). I don't introduce artificial scopes either. However, I do try to declare variables in the most-tightly-enclosing scope. For example, if a variable is only used in one branch of an if statement, declare the variable inside that block, not in the enclosing scope. I also find that if you're declaring a lot of variables in a single block, that's usually a sign that the block is too large and should be refactored (e.g. by moving some code into separate functions). If you keep your functions manageably small (which is not always the case in the Postgres code, unfortunately), the declarations are usually pretty clearly visible. -Neil [1] http://advogato.org/person/nconway/diary.html?start=24 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Design Considerations for New Authentication Methods
* Martijn van Oosterhout (kleptog@svana.org) wrote: In postgresql the client and server can specify what certificates thay'll accept, there are no default trusted CAs. You can require the client to have a certain certificate, for example. The client can also verify the server has the expected certificate. How much it's used I don't know, but SSL does support it. I don't think you can tie the SSL certificate to a specific user though... I certainly can't recall any way to do that today in PG. That would be possible w/ SASL/EXTERNAL though, I believe. The encryption of a channel has nothing to do with verifying the client/server is who they say they are. They can be configured independantly. You can block Man-in-the-middle attacks without encrypting the channel, though it is unusual. They don't have to be connected, that's true. In general I think it's better when they can be though. I guess this discussion makes it sound like I've convinced myself to use SASL. I still need to resolve how to do name translation. PostgreSQL wants a single unix-like name, and I haven't looked at how to properly do that translation from SASL (or GSSAPI) names. Usually a field in the certificate is the username postgresql wants, which can be mapped via a table. For SASL I don't know. I expect we'll need a mapping of some sort, or perhaps a sasl_regexp or similar to what is done in OpenLDAP. I don't recall PG supporting using the DN from a client cert in an SSL connection as a PG username but perhaps I missed it somewhere... Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Design Considerations for New Authentication Methods
In postgresql the client and server can specify what certificates thay'll accept, there are no default trusted CAs. You can require the client to have a certain certificate, for example. The client can also verify the server has the expected certificate. How much it's used I don't know, but SSL does support it. I don't think you can tie the SSL certificate to a specific user though... I certainly can't recall any way to do that today in PG. You can't. It's been talked about, but never done. I guess this discussion makes it sound like I've convinced myself to use SASL. I still need to resolve how to do name translation. PostgreSQL wants a single unix-like name, and I haven't looked at how to properly do that translation from SASL (or GSSAPI) names. Usually a field in the certificate is the username postgresql wants, which can be mapped via a table. For SASL I don't know. I expect we'll need a mapping of some sort, or perhaps a sasl_regexp or similar to what is done in OpenLDAP. I don't recall PG supporting using the DN from a client cert in an SSL connection as a PG username but perhaps I missed it somewhere... You can't today. If we want to add username mapping in SASL or whatever, it might be a good idea to look at generalizing the authuser-to-dbuser mapping stuff (like we have for identmap now) into something that can be used for all external auth methods. Instead of inventing one for every method. //Magnus ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Coding style question
[EMAIL PROTECTED] writes: initializers also force you to declare variables in the scope where they are needed. Instead of declaring every variable at the start of the function, it's better to declare them as nested as practical (not as nested as possible, but as nested as practical). I agree that in many places it'd be better style to declare variables in smaller scopes ... but that's not the point you started the thread with. In any case, the initializer-vs-assignment decision is the same no matter what scope you're talking about --- I don't see how that forces you to do it either way. Right - I should have said that proper initialization encourages you to declare variables in nested scopes (proper meaning that the initializer puts a meaningful value into the variable, not just a default NULL or 0) - if the initializer depends on a computed value, you can't initialize until that value has been computed. I guess the two issues are not all that related - you can initialize without nesting (in many cases) and you can nest without initializing. They are both readability and maintainability issues to me. Thanks for the feedback. -- Korry
Re: [HACKERS] Coding style question
Well, clearly you should only assign meaningful values to variables, but I don't see anything wrong with omitting an initializer, initializing the variable before using it, and letting the compiler warn you if you forget to do this correctly. The problem that that introduces is that you have to unravel the code if you want to maintain it, especially if you're changing complex code (many code paths) and some variable is initialized long after it's declared. You have to search the code to figure out at which point the variable gains a meaningful value. In the example I cited, each variable was assigned a value immediately after being declared. That wasn't a good example - in some places, we declare all variables at the start of the function, but we don't assign a value to some of the variables until 20 or 30 lines of code later (and if there are multiple code paths, you have to follow each one to find out when the variable gains a meaningful value). I agree with Greg's rationale on when to include an initializer in a variable declaration (when the initializer is trivial: e.g. casting a void * to a more specific pointer type, or using one of the PG_GETARG_XXX() macros in a UDF). I agree too. I wasn't trying to suggest that every variable must be initialized. I think Tom stated it pretty well: When the variable is going to be set anyway in straight-line code at the top of the function, then it's mostly a matter of taste whether you set it with an initializer or an assignment. the key phrase is: set anyway in straigh-tline code at the top of the function (I don't go so far as to introduce artificial scopes just for the sake of nesting variable declarations). I don't introduce artificial scopes either. However, I do try to declare variables in the most-tightly-enclosing scope. For example, if a variable is only used in one branch of an if statement, declare the variable inside that block, not in the enclosing scope. good... I also find that if you're declaring a lot of variables in a single block, that's usually a sign that the block is too large and should be refactored (e.g. by moving some code into separate functions). If you keep your functions manageably small (which is not always the case in the Postgres code, unfortunately), the declarations are usually pretty clearly visible. I couldn't agree more. Thanks for your comments. -- Korry
Re: [HACKERS] Design Considerations for New Authentication Methods
On Thu, 2 Nov 2006, Magnus Hagander wrote: I expect we'll need a mapping of some sort, or perhaps a sasl_regexp or similar to what is done in OpenLDAP. I don't recall PG supporting using the DN from a client cert in an SSL connection as a PG username but perhaps I missed it somewhere... You can't today. If we want to add username mapping in SASL or whatever, it might be a good idea to look at generalizing the authuser-to-dbuser mapping stuff (like we have for identmap now) into something that can be used for all external auth methods. Instead of inventing one for every method. //Magnus Well, there's simply no need. While I can agree that more could be done, I'm not convinced there's a need because what we have now works fine. Let me support my view by stating first that I perceive that combining the conception of encrypting a communications channel with user authentication to be a very poor choice. I gather from the paragraph above that this is a forgone conclusion. Appologies if I'm mistaken. Just so my point - that another strategy is not needed - is understood, let's agree that SSL is just preventing sniffers from capturing whatever else goes on in our conversation. Great. What's inside that communication? Why, there's a perfectly workable username/password authentication that happens! Sure, someone could steal that data somehow and break in, but that requires one of the two systems to be breached, and that's a security problem that's out of scope for Postgres. Would signed certificates be preferred? Well, sure, they're nice. I don't object, and in fact welcome some improvements here. For example, I'd love the choice of taking an individual user's certificate and authenticating completely based upon that. However, while this _seems_ to simplify things, it really just trades off with the added cost of managing those certs - username/password is slam-dunk simple and has the advantage that users can share one authentication. Unless I've really overlooked something basic, there's nothing lacking in the existing scheme... Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Design Considerations for New Authentication Methods
* Richard Troy ([EMAIL PROTECTED]) wrote: Would signed certificates be preferred? Well, sure, they're nice. I don't object, and in fact welcome some improvements here. For example, I'd love the choice of taking an individual user's certificate and authenticating completely based upon that. However, while this _seems_ to simplify things, it really just trades off with the added cost of managing those certs - username/password is slam-dunk simple and has the advantage that users can share one authentication. Username/password is not acceptable in a number of situations. This is not intended to replace them. This would be in *addition* to supporting the current auth methods. I don't understand at all how you feel it'd be nice to have yet shouldn't be done. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Design Considerations for New Authentication Methods
Username/password is not acceptable in a number of situations. This is not intended to replace them. This would be in *addition* to supporting the current auth methods. I don't understand at all how you feel it'd be nice to have yet shouldn't be done. Thanks, Stephen ...I thought you said this _needs_ to be done - by using words like unacceptible and required - and I disagree. There's a difference between what needs to be done and what is desired to be done. Further, I never said shouldn't. Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Design Considerations for New Authentication Methods
* Richard Troy ([EMAIL PROTECTED]) wrote: ...I thought you said this _needs_ to be done - by using words like unacceptible and required - and I disagree. There's a difference between what needs to be done and what is desired to be done. Further, I never said shouldn't. For PG to be an option in certain environments, it *needs* to be done because in those environments username/password are *unacceptable*. Additionally, there's someone (actually, more than one it seems) who's willing to spend the time and energy to implement it. If it's not necessary for your environment, great! If you weren't suggesting it shouldn't be implemented or accepted then I've truely got no idea what the intent of your previous mail was. Enjoy, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Design Considerations for New Authentication Methods
On Nov 2, 2006, at 12:26 PM, Richard Troy wrote: Well, there's simply no need. While I can agree that more could be done, I'm not convinced there's a need because what we have now works fine. Let me support my view by stating first that I perceive that combining the conception of encrypting a communications channel with user authentication to be a very poor choice. I gather from the paragraph above that this is a forgone conclusion. Apologies if I'm mistaken. Understand that I'm talking about *real* security here. There are standard protocols and libraries that support real security: SASL and GSSAPI in particular. You may for various reasons decide that it's too hard to do real security. Most people don't, including most people who use SSL. I'm not saying that's *wrong*, just that some possible attack methods have not been prevented. At the level of detail that's appropriate for this list, all I can do is repeat myself. Part of establishing a secure connection is establishing that the end points are the intended ones and there is no Man In the Middle. Establishing the end points means the server has identified the user within the name space of the security mechanism. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Design Considerations for New Authentication Methods
Would signed certificates be preferred? Well, sure, they're nice. I don't object, and in fact welcome some improvements here. For example, I'd love the choice of taking an individual user's certificate and authenticating completely based upon that. However, while this _seems_ to simplify things, it really just trades off with the added cost of managing those certs - username/password is slam-dunk simple and has the advantage that users can share one authentication. Unless I've really overlooked something basic, there's nothing lacking in the existing scheme... From my POV, yes, you are missing sometihng very basic - single signon. This is what Kerberos gives me. No need for the user to type in his password, becaus ehe is *already* logged in and authenticated by a trusted KDC in the realm. The same could apply to SSL cert based authentication, for users connecting from machines outside of my realm. Once you have unlocked the certificate, you can authenticate any number of times to any number of services that will accept this certificate *without* having to re-enter your password. This is both a convenience for the user, and a requirement if you use OTPs. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] WAL logging freezing
I wrote: * pg_clog is truncated according to the oldest pg_database.datvacuumxid. While testing this patch I realized that there's a bit of an issue here. It's usually going to be the case that the oldest datvacuumxid is template0's, meaning that it will never be possible to truncate clog until autovacuum decides that template0 is at risk of wraparound and goes and vacuums it. Shortening the freeze horizon will reduce the size that pg_clog occupies just *after* that happens, but we're still going to see pg_clog bloating up to something close to 256MB before autovacuum kicks in. And there is nothing a user can do about it, unless he's willing to override the datallowconn = false safety cover on template0 so he can connect to it and vacuum it manually. This wasn't a problem in the pre-8.2 logic because we ignored non-connectable databases while determining the global minimum datvacuumxid, but it's a real problem now. Seems like either we go back to ignoring non-connectable databases (with the risks that entails), or adopt some more-aggressive policy for launching autovacuums on them, or give up the idea of keeping pg_clog small. A more-aggressive policy seems like the best option, but I'm not entirely sure what it should look like. Maybe force autovacuum when age(datvacuumxid) exceeds twice the freeze horizon, or some such? Comments? regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Design Considerations for New Authentication Methods
On Thu, Nov 02, 2006 at 01:10:14PM -0800, Henry B. Hotz wrote: standard protocols and libraries that support real security: SASL and GSSAPI in particular. You may for various reasons decide that [. . .] Part of establishing a secure connection is establishing that the end points are the intended ones and there is no Man In the Middle. Establishing the end points means the server has identified the user within the name space of the security mechanism. For what it's worth, I heartily support this effort. For most cases, it probably isn't necessary, but I can think of several applications for SASL/GSSAPI where something weaker will simply not do; in the absence of the proposed functionality, I simply wouldn't be able to use Postgres for those applications. A -- Andrew Sullivan | [EMAIL PROTECTED] In the future this spectacle of the middle classes shocking the avant- garde will probably become the textbook definition of Postmodernism. --Brad Holland ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Design Considerations for New Authentication Methods
On Thu, Nov 02, 2006 at 08:58:37PM +0100, Magnus Hagander wrote: I don't think you can tie the SSL certificate to a specific user though... I certainly can't recall any way to do that today in PG. You can't. It's been talked about, but never done. Oops, sorry. You can verify the user has a valid certificate, but you can't use it for authentication. AFAIK it just needs to be coded (certainly the code to get the relevent fields from the certificate is there). Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
[HACKERS] Force 8.2 initdb to rename pg_database/pg_class minxid columns?
Yesterday I wrote: * On successful completion, the cutoff XID is stored in pg_class.relvacuumxid, and pg_database.datvacuumxid is updated if appropriate. (The minxid columns are now useless, but unless there is another reason to force initdb before 8.2, I'm inclined to leave them there and unused. We can remove 'em in 8.3.) After a closer look I am thinking that maybe we should go ahead and replace relvacuumxid/relminxid and datvacuumxid/datminxid by single columns named relfrozenxid and datfrozenxid respectively. The reason is that our documentation has for a long time recommended SELECT datname, age(datfrozenxid) FROM pg_database; as a good way to check for databases approaching wraparound. (In fact it still does ... apparently Alvaro didn't bother to update maintenance.sgml when he redid that code.) I don't know how many people might have such queries embedded in maintenance scripts, but any who do will find their scripts broken by 8.2 as it now stands. Which is a bit silly considering that the proposed patch will be maintaining a column having exactly the longstanding definition of datfrozenxid: All rows inserted by transaction IDs before this one have been relabeled with a permanent (quotefrozen/) transaction ID in this database. I prefer to avoid forcing initdb in late beta, because it causes extra work for our long-suffering beta testers, but at the moment I'm thinking this is worth fixing now rather than later. Comments? regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Design Considerations for New Authentication Methods
On Thu, Nov 02, 2006 at 10:48:29PM +0100, Magnus Hagander wrote: The same could apply to SSL cert based authentication, for users connecting from machines outside of my realm. Once you have unlocked the certificate, you can authenticate any number of times to any number of services that will accept this certificate *without* having to re-enter your password. Why would you need to unlock it? SSL certificate is effectively a password stored in a file of length 1024 bits or whatever. This is both a convenience for the user, and a requirement if you use OTPs. I don't understand the OTP part. Single signon is only a convenience. Ability to resume a session (provided by SSL) or ability to login using a smaller authentication token than a certificate can be used to provide performance improvement. If the requirement is that no password is provided, password + SSL certificate is not an improvement. Any token based authentication system should allow for the token to become invalid at any time, and require re-authentication using the primary mechanism. The benefit to kerberos, from my perspective, is that it already exists, and is widely used. I prefer SSL certificates alone myself. All of my db passwords are randomly generated anyways, and a 1024-bit randomly generated password is better than a 64-bit password picked by a person at a keyboard. Having both isn't an improvement I think. My own system at home uses RSA keys or SSH entry. I don't bother with passwords anymore. If they can access my password, they can access my certificate. If they can access my certificate, they can access my password. Dual authentication models work better with very different systems. For example, a USB key or digital display that I possess, and a password that I know or have stored in a file. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Force 8.2 initdb to rename pg_database/pg_class minxid columns?
On Thu, Nov 02, 2006 at 05:22:39PM -0500, Tom Lane wrote: I prefer to avoid forcing initdb in late beta, because it causes extra work for our long-suffering beta testers, but at the moment I'm thinking this is worth fixing now rather than later. Comments? Given that the column name change entails backwards incompatibility for many users, and the change no longer signifies an actual change to underlying functionality, though, it seems worth the pain to me. A -- Andrew Sullivan | [EMAIL PROTECTED] The fact that technology doesn't work is no bar to success in the marketplace. --Philip Greenspun ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] WAL logging freezing
On Thu, 2006-11-02 at 16:50 -0500, Tom Lane wrote: I wrote: * pg_clog is truncated according to the oldest pg_database.datvacuumxid. Shortening the freeze horizon will reduce the size that pg_clog occupies just *after* that happens, but we're still going to see pg_clog bloating up to something close to 256MB before autovacuum kicks in. Well, by default a Windows install is about 80MB, plus 7x 16MB WAL gives nearly 200MB, so we're talking about the doubling the basic on-disk footprint for every user if we let that happen. This wasn't a problem in the pre-8.2 logic because we ignored non-connectable databases while determining the global minimum datvacuumxid, but it's a real problem now. Seems like either we go back to ignoring non-connectable databases (with the risks that entails), or adopt some more-aggressive policy for launching autovacuums on them, or give up the idea of keeping pg_clog small. A more-aggressive policy seems like the best option, but I'm not entirely sure what it should look like. Maybe force autovacuum when age(datvacuumxid) exceeds twice the freeze horizon, or some such? Comments? Given many users are individual PCs, or at least stand-alone servers not in constant use, then I think more aggressive vacuuming makes sense as a way to keep clog smaller. In many situations the time lost through continually virus scanning databases will be more than if we do a more regular autovacuum, so we shouldn't really worry about that. Sounds like we need a GUC for those who don't care about 256MB though, but may care about autovacuum switching in at bad moments. Also, that solution doesn't square with the current autovacuum defaults: We should set autovacuum on by default, with autovacuum_vacuum_cost_delay = 10 by default. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Design Considerations for New Authentication Methods
All, For what it's worth, I heartily support this effort. For most cases, it probably isn't necessary, but I can think of several applications for SASL/GSSAPI where something weaker will simply not do; in the absence of the proposed functionality, I simply wouldn't be able to use Postgres for those applications. I'll also add that there are an increasing number of apps and authentication environments which use SASL or GSSAPI. Supporting these means that we are no longer locked out of those companies. I know that the Solaris folks would prefer us to use GSSAPI. And if there is some reasonably large number of people using a particular athentication method, we should support it if someone is offering us the code. Why would we reject a piece of useful functionality based on a published standard? -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Design Considerations for New Authentication Methods
Josh Berkus josh@agliodbs.com writes: ... Why would we reject a piece of useful functionality based on a published standard? Well, size and maintainability of the proposed patch are certainly factors in any such decision. As a closely related example, I bet we'd have rejected the original Kerberos-support patch if we'd known then what we know now. It's been a constant source of bugs ever since it went in, and with so few users of the feature, it takes a long time to find the problems. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Design Considerations for New Authentication Methods
Tom Lane wrote: Josh Berkus josh@agliodbs.com writes: ... Why would we reject a piece of useful functionality based on a published standard? Well, size and maintainability of the proposed patch are certainly factors in any such decision. As a closely related example, I bet we'd have rejected the original Kerberos-support patch if we'd known then what we know now. It's been a constant source of bugs ever since it went in, and with so few users of the feature, it takes a long time to find the problems. To be honest, I have often wondered *why* we support kerberos outside of the uber l33t geek factor. I have not once in a commercial deployment had a business requirement for the beast. LDAP? Now that is a whole other issue :) Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [BUGS] bug in timestamp and out of range values
On Thursday 02 November 2006 17:48, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
pagila=# select to_date('3232098', 'MM/DD/');
to_date
---
4568-06-26 BC
(1 row)
to_date's absymal lack of error checking is well known. It should
surely refuse that input altogether, given that format string.
Feel free to send a patch ...
As for the range issue, date_in does refuse negative Julian dates:
regression=# select '4714-01-27 BC'::date;
ERROR: date out of range: 4714-01-27 BC
but again to_date doesn't:
regression=# select to_date('4714-01-27 BC', '-MM-DD BC');
to_date
---
4714-01-27 BC
(1 row)
I'm not concerned about to_date so much as I am that timestamp_in lets you
store values you can't read with timestamp_out. Once the value is in there
you can happily move it around with create table as and such...
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Design Considerations for New Authentication Methods
* Tom Lane ([EMAIL PROTECTED]) wrote: Josh Berkus josh@agliodbs.com writes: ... Why would we reject a piece of useful functionality based on a published standard? Well, size and maintainability of the proposed patch are certainly factors in any such decision. As a closely related example, I bet we'd have rejected the original Kerberos-support patch if we'd known then what we know now. It's been a constant source of bugs ever since it went in, and with so few users of the feature, it takes a long time to find the problems. Funny, I really wonder why you feel there's few users of it. I use kerberos auth on quite a few hosts and I've heard of at least a couple others on this (not all that frequented) list. Kerberos is really rather popular, made more so through SSPI and GSSAPI... Thanks Stephen signature.asc Description: Digital signature
Re: [HACKERS] Design Considerations for New Authentication Methods
On Thu, Nov 02, 2006 at 07:49:01PM -0800, Joshua D. Drake wrote: To be honest, I have often wondered *why* we support kerberos outside of the uber l33t geek factor. I have not once in a commercial deployment had a business requirement for the beast. LDAP? Now that is a whole other issue :) Isn't NFSv4 a big application that uses Kerberos? I seem to recall that AFS may have been a large user as well. The only reason it isn't widely used is because companies are slow to change. We still use NIS for host names in too many places! Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [BUGS] bug in timestamp and out of range values
but again to_date doesn't:
regression=# select to_date('4714-01-27 BC', '-MM-DD BC');
to_date
---
4714-01-27 BC
(1 row)
I'm not concerned about to_date so much as I am that timestamp_in lets you
store values you can't read with timestamp_out. Once the value is in there
you can happily move it around with create table as and such...
Hmmm... if that is the case, I would also have a pretty significant
concern. We have basically created an environment that is unreliable
during a restore. Not to mention violating data type constraints.
postgres=# create table timetest (test date);
CREATE TABLE
postgres=# insert into timetest
values (to_date('4714-01-27 BC', '-MM-DD BC'));
INSERT 159911984 1
postgres=# select '4714-01-27 BC'::date;
ERROR: date out of range: 4714-01-27 BC
postgres=# select cast(test as date) from timetest;
test
---
4714-01-27 BC
(1 row)
postgres=#
postgres=# select cast('4714-01-27 BC' as date);
ERROR: date out of range: 4714-01-27 BC
postgres=#
This seems pretty broken.
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
[HACKERS] recovering prepared transaction after server restart message
There have been several reports that people could not vacuum any more or observed strange locks even after server restart. The reason was that they still had uncommitted prepared transactions around. I wonder if it could help to change the log level from ereport(LOG, (errmsg(recovering prepared transaction %u, xid))); to WARNING maybe in order to make that message more striking within the normal startup messages. Joachim ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [BUGS] bug in timestamp and out of range values
postgres=# select '4714-01-27 BC'::date;
ERROR: date out of range: 4714-01-27 BC
postgres=# select cast(test as date) from timetest;
test
---
4714-01-27 BC
(1 row)
postgres=#
postgres=# select cast('4714-01-27 BC' as date);
ERROR: date out of range: 4714-01-27 BC
postgres=#
This seems pretty broken.
Joshua D. Drake
And further this with timestamp instead of date:
postgres=# create table timestamptest(test timestamp);
CREATE TABLE
postgres=# insert into timestamptest
values (to_date('4714-01-27 BC', '-MM-DD BC'));
INSERT 159911988 1
postgres=# select * from timestamptest;
ERROR: timestamp out of range
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] recovering prepared transaction after server restart message
Joachim Wieland [EMAIL PROTECTED] writes: There have been several reports that people could not vacuum any more or observed strange locks even after server restart. The reason was that they still had uncommitted prepared transactions around. I wonder if it could help to change the log level from ereport(LOG, (errmsg(recovering prepared transaction %u, xid))); to WARNING maybe in order to make that message more striking within the normal startup messages. That doesn't seem like a good idea. In the first place, recovering prepared xacts is exactly what system restart is *supposed* to do, and so calling it a WARNING seems out of line. (I'm not real sure why that message is even LOG level, rather than DEBUG1 or below.) In the second place, this wouldn't help anyone unless they tried to fix their problem by restarting the server --- a mentality suited only for Windows users, and certainly not something a production system is going to do lightly --- and then thought to look in the postmaster log, which the average Windows user wouldn't. I agree that there's a usability issue here though; I've been burnt by forgotten prepared xacts myself (eg by control-C'ing pg_regress at just the wrong time). Would it help if we included prepared xacts in the pg_stat_activity view? Is there any other place we could make them more visible during normal server operation? regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Design Considerations for New Authentication Methods
The same could apply to SSL cert based authentication, for users connecting from machines outside of my realm. Once you have unlocked the certificate, you can authenticate any number of times to any number of services that will accept this certificate *without* having to re-enter your password. Why would you need to unlock it? SSL certificate is effectively a password stored in a file of length 1024 bits or whatever. Because if someone can access this file, I don't want them to automticlly be me. Say this file is on my smartcard - I most certainly want a PIN code before it logs me in. Now, if I trust my local machine reasonably well, this unlock can equal the local login. But there's still an unlock sequence. This is both a convenience for the user, and a requirement if you use OTPs. I don't understand the OTP part. Single signon is only a convenience. Ability to resume a session (provided by SSL) or ability to login using a smaller authentication token than a certificate can be used to provide performance improvement. OTP can certainly be a *lot* more secure, when used in the right way. This of course rquires you use a two-factor system such as a token based key or challenge/response system. And it's not just a convenience. SSL reusme session doesn't work if the first login is to my fileserver, the second to my maliserver and the third to my database server. I would then require three separate OTP logins. Since they would normally have a time-window, it will also noticably slow down the process since I'd have to wait for a new key before accessing each resource. The benefit to kerberos, from my perspective, is that it already exists, and is widely used. Yes, that is a huge benefit. My own system at home uses RSA keys or SSH entry. I don't bother with passwords anymore. If they can access my password, they can access my certificate. If they can access my certificate, they can access my password. Dual authentication models work better with very different systems. For example, a USB key or digital display that I possess, and a password that I know or have stored in a file. Well, you know how to deal with passwords and authentication. Most users don't. Therefor using things like smartcard+PIN can *both* increase security *and* make things easier for them. To make it work in reality, that means you need to support whatever infrastructure standard other systems use, and that's most commonly Kerberos today. And second most common I would beleive is SSL/TLS certs. //Magnus ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Design Considerations for New Authentication Methods
... Why would we reject a piece of useful functionality based on a published standard? Well, size and maintainability of the proposed patch are certainly factors in any such decision. As a closely related example, I bet we'd have rejected the original Kerberos-support patch if we'd known then what we know now. It's been a constant source of bugs ever since it went in, and with so few users of the feature, it takes a long time to find the problems. To be honest, I have often wondered *why* we support kerberos outside of the uber l33t geek factor. I have not once in a commercial deployment had a business requirement for the beast. LDAP? Now that is a whole other issue :) Single sign-on in a Windows/AD environment (I'm talking clients on windows, servers on linux here - at least in my case). I know several people who use it, most just don't post here ;-) Now, it would likely be a lot *easier* to do this with GSSAPI than the pure kerberos stuff we have now, given that the Windows native APIs support GSSAPI compatible stuff, but not the stuff we have now. //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Design Considerations for New Authentication Methods
To be honest, I have often wondered *why* we support kerberos outside of the uber l33t geek factor. I have not once in a commercial deployment had a business requirement for the beast. LDAP? Now that is a whole other issue :) Isn't NFSv4 a big application that uses Kerberos? I seem to recall that AFS may have been a large user as well. AFS definitly used it. But if you're looking for a big application that uses Kerberos, there's that pesky thing called Windows. Every single Windows machine in an active directory domain environment is a Kerberos client, and uses Kerberos for authentication to all network services. So Kerberos is definitly big. And more and more apps do support GSSAPI for authentication. Not that many apps support raw kerberos as pgsql does, probably because it does have some compatibility issues and such things. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Design Considerations for New Authentication Methods
On Fri, Nov 03, 2006 at 08:05:05AM +0100, Magnus Hagander wrote: The same could apply to SSL cert based authentication, for users connecting from machines outside of my realm. Once you have unlocked the certificate, you can authenticate any number of times to any number of services that will accept this certificate *without* having to re-enter your password. Why would you need to unlock it? SSL certificate is effectively a password stored in a file of length 1024 bits or whatever. Because if someone can access this file, I don't want them to automticlly be me. Say this file is on my smartcard - I most certainly want a PIN code before it logs me in. Now, if I trust my local machine reasonably well, this unlock can equal the local login. But there's still an unlock sequence. Yes - local login. I didn't think of it in that context, as I think more of batch processes, or servers accessing the database. A person accessing just doesn't seem significant to me. It's more of a special case. :-) I prefer to use PostgreSQL with a local socket, and passing of UNIX credentials over the socket. If you can login to the account, you can access all of the scripts owned by that account that have a PostgreSQL username/password embedded within them anyways - so why embed at all? Obviously, for remote database access, or for any system with load sharing across systems accessing the same database, this doesn't work too well and an alternative such as SSL certificates becomes desirables. The effect is the same, though. I don't understand the OTP part. Single signon is only a convenience. Ability to resume a session (provided by SSL) or ability to login using a smaller authentication token than a certificate can be used to provide performance improvement. OTP can certainly be a *lot* more secure, when used in the right way. This of course rquires you use a two-factor system such as a token based key or challenge/response system. Not sure why it would be more secure by using a smaller key on second entry. Sure the smaller key times out, but effectively you now have two or more keys instead of one. :-) And it's not just a convenience. SSL reusme session doesn't work if the first login is to my fileserver, the second to my maliserver and the third to my database server. I would then require three separate OTP logins. *nod* Since they would normally have a time-window, it will also noticably slow down the process since I'd have to wait for a new key before accessing each resource. This presumes that you use a key system. SSL certificate is adequate on its own for many uses... :-) The benefit to kerberos, from my perspective, is that it already exists, and is widely used. Yes, that is a huge benefit. Ignoring my liking of SSL certificates, and my defense of them, I agree it is a huge benefit to support Kerberos for these reasons. My own system at home uses RSA keys or SSH entry. I don't bother with passwords anymore. If they can access my password, they can access my certificate. If they can access my certificate, they can access my password. Dual authentication models work better with very different systems. For example, a USB key or digital display that I possess, and a password that I know or have stored in a file. Well, you know how to deal with passwords and authentication. Most users don't. Therefor using things like smartcard+PIN can *both* increase security *and* make things easier for them. To make it work in reality, that means you need to support whatever infrastructure standard other systems use, and that's most commonly Kerberos today. And second most common I would beleive is SSL/TLS certs. *nod* I agree. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [BUGS] bug in timestamp and out of range values
Robert Treat [EMAIL PROTECTED] writes: I'm not concerned about to_date so much as I am that timestamp_in lets you store values you can't read with timestamp_out. Your example does not demonstrate any such thing. What it demonstrates is that to_date will let an out-of-range date into the system, not that timestamp_in will. Counterexample: regression=# select '4714-01-27 BC'::timestamp; ERROR: timestamp out of range: 4714-01-27 BC regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
