Re: [HACKERS] Re: Encrypting pg_shadow passwords
On Tue, Jul 10, 2001 at 11:32:00PM -0400, Bruce Momjian wrote: On Tue, Jun 26, 2001 at 11:02:15AM -0400, Bruce Momjian wrote: This is the first time I am hearing people are more concerned about pg_shadow security than the wire security. I can see cases where people are on secure networks or are using only local users where having pg_shadow encrypted is more important than crypt authentication. Fortunately the new system will solve both problems. The crypt authentication currently used offers _no_ security. If I can sniff on the wire, I can hijack the tcp stream, and trick the client into doing password authentication. It is my understanding that sniffing is much easier than hijacking. If hijacking is a concern, you have to use SSL. That is not true. The internet happily allows for active attacks. In fact, active attacks are easier on the internet than passive ones. My concern is, that by having something that we proclaim to be secure, we need for it to really be secure. An HMAC would be a better alternative to the current crypt scheme, as it would provide integrity, without the overhead of having privacy. Of course, HMAC would require the postgres protocol to talk in packets, as it can't accept the data as being valid until it verifies the MAC. I'm not familiar with the protocol yet. I suggest these authentication options: * password - The current meaning of password, but with passwords hashed using md5crypt() or something. (The usual crypt unneccessarily limits passwords to 8 characters) * HMAC - Wrap all postgres data in an HMAC (I believe this requires an plaintext-like password on the server as does crypt and the double crypt scheme) * Public Key (RSA/DSA) - Use public key cryptography to negotiate a connection. (When I'm not busy, I may decide to do this myself) Also, I think we should add to the client API the ability to only accept certain authentication schemes, to avoid active attacks tricking your software from sending the HMAC password in cleartext. -- Michael Samuel [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Re: Encrypting pg_shadow passwords
On Tue, Jun 26, 2001 at 11:02:15AM -0400, Bruce Momjian wrote: This is the first time I am hearing people are more concerned about pg_shadow security than the wire security. I can see cases where people are on secure networks or are using only local users where having pg_shadow encrypted is more important than crypt authentication. Fortunately the new system will solve both problems. The crypt authentication currently used offers _no_ security. If I can sniff on the wire, I can hijack the tcp stream, and trick the client into doing password authentication. Also, the double crypt authentication offers no advantage over the wire. You're better off just doing an md5crypt() on the server side, and just passing the password in the clear. At least you're not confusing users into thinking that they're secure. Of course, SSL *if done correctly with certificate verification* is the correct fix. If no certificate verification is done, you fall victim to a man-in-the-middle attack. -- Michael Samuel [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Support for %TYPE in CREATE FUNCTION
I've been thinking about this, and I think the smartest way to implement
%TYPE would be to have it as a special-case data type. So, the C
representation of it would be something like this:
struct PercentType {
int datatype;
void *data;
};
Note: I made the datatype field an int, but that may/may not be the
correct datatype to use there.
And basically, postgres can resolve at runtime what it should point to,
and the code should have to deal with it, either via casting, or throwing
an exception if it's unacceptable.
Of course, there'd be a small overhead within the function, but it's a
small price to pay for a robust implementation.
As for operator overloading, a decision must be made whether you search
for a more specific function first, or for a matching %TYPE.
Of course, this may be too many special cases to be coded cleanly...
--
Michael Samuel [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] Support for %TYPE in CREATE FUNCTION
On Wed, May 30, 2001 at 12:30:23PM -0400, Tom Lane wrote: Actually that's the least of the issues. The real problem is that because of function overloading, myfunc(int4) and myfunc(int2) (for example) are considered completely different functions. It is thus not at all clear what should happen if I create myfunc(foo.f1%TYPE) and later alter the type of foo.f1 from int4 to int2. Does myfunc(int4) stop existing? What if a conflicting myfunc(int2) already exists? What happens to type-specific references to myfunc(int4) --- for example, what if it's used as the implementation function for an operator declared on int4? Would the idea of %TYPE being considered a default type, so it won't conflict with any more specific functions be out of the question? For example, if I call myfunc(int4), it'll first check if there's a myfunc(int4), then failing that, check if there's a myfunc(foo.bar%TYPE). Umm.. of course, there's no reason why it should search in that order, because checking for myfunc(foo.bar%TYPE) first would be just as valid, but either way, it's a well defined semantic. -- Michael Samuel [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Fix for tablename in targetlist
On Sat, May 19, 2001 at 10:50:31AM -0400, Tom Lane wrote: I had a thought this morning that raising an error may be the wrong thing to do. We could instead choose to expand the name into pg_class.*, which would take only a little more code and would arguably do something useful instead of useless. (I suspect that the fjoin stuff that still remains in the backend was originally designed to support exactly this interpretation.) This is almost certainly the wrong thing to do. It would introduce ambiguity to the syntax, that can only be error prone in the long run. What happens if people put that kind of query in a view, or hard coded into a program somewhere, then later decide to ALTER TABLE to add a column by that name? If somebody forgets the .*, they should reasonably expect an error message. (And, I would personally be annoyed if I didn't get one, and instead my incorrect query went through) -- Michael Samuel [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: New Linux xfs/reiser file systems
On Thu, May 03, 2001 at 11:41:24AM -0400, Bruce Momjian wrote: ext2 has serious problems with corrupt file systems after a crash, so I understand the need to move to another file system type. I have been waitin for Linux to get a more modern file system. Unfortunately, the new ones seem to be worse for PostgreSQL. If you fsync() a directory in Linux, all the metadata within that directory will be written out to disk. As for filesystem corruption, I can say the e2fsck is among the best fsck programs out there, and I've only ever had 1 occasion where I've lost any data on an ext2 filesystem, and that was due to bad sectors causing me to lose the root directory. (Well, apart from human errors, but that doesn't count) OK, we have considered this, but frankly, the new, modern file systems like FFS/softupdates have i/o rates near raw speed, with all the advantages a file system gives us. I believe most commercial dbs are moving away from raw devices and toward file systems. In the old days the SysV file system was pretty bad at i/o fragmentation, so they used raw devices. And Solaris' 1/01 media has better support for O_DIRECT (?), which they claim gives you 93% of the speed of a raw device. (Or something like that; I read this in marketing material a couple of months ago) Raw devices are designed to have filesystems on them. The only excuses for userland tools accessing them, are fs-specific tools (eg. dump, fsck, etc), or for non-unix filesystem tools, where the unix VFS doesn't handle things properly (hfstools). The ability to put indexes on a separate volume from data. The ability to put different tables on different volumes. And so on. We certainly need that, but raw devices would not make this any easier, I think. It would be cool if either at compile time or at database creation time, we could specify a printf-like format for placing tables, indexes, etc. It could become a serious problem as people start using reiser/xfs for their file systems and don't understand the performance problems. Even more likely is that they will turn off fsync, thinking reiser doesn't need it, when in fact, I think it does. ReiserFS only supports metadata logging. The performance slowdown must be due to logging things like mtime or atime, because otherwise ReiserFS is a very high performance FS. (Although, I admittedly haven't used it since it was early in it's development) -- Michael Samuel [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Thanks, naming conventions, and count()
On Sun, Apr 29, 2001 at 08:17:28PM -0700, Alfred Perlstein wrote: Sort of, if that flat file is in the form of: 123456;tablename 33;another_table Or better yet, since the flat file is unlikely to be large, you could just do this dance: 1) open file for reading 2) flock() file exclusively, non-blocking. 3) If 2 failed, sleep a bit, then go back to 1, otherwise open new file for writing 4) Write out new file 5) rename() the temp file over the new file 6) close files, etc That way, you'll never have the race of 2 programs trying to write the file at a time (therefore losing changes), and you get total atomicity of the writing. You could also do it with an open(O_EXCL) on a fixed temp file, instead of the flock() call. The semantics should be the same. Of course, you could always fork() a child to handle this in the background, as it's hardly important to the running of the database. (Or if it is, it can become part of the transaction, which means that at rename() time, there must be no room for other failures, but it mustn't be too late to roll back) -- Michael Samuel [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
