On Wed, 2005-06-08 at 10:00 -0700, dong changyu wrote:
Hi,
A possible countermeasure on Windows platform,
inspired by Magnus.Thanks ;)
First we remove the passphrase from the key file,
making it plain.
Windows provides a feature encrypted file system,
provide transparent
Hi Marco,
The problem I described in the first mail is that
because of some unknown reasons, if you save the
server.key file with a passphrase, you will be
prompted to enter the passphrase every time you start
the server AND a client make a connection, which
actually forbids us to use a passphrase
On Thu, 2005-06-09 at 02:59 -0700, Changyu Dong wrote:
Hi Marco,
The problem I described in the first mail is that
because of some unknown reasons, if you save the
server.key file with a passphrase, you will be
prompted to enter the passphrase every time you start
the server AND a client
The EFS encryption as you described it adds nothing but a
false sense of security (and the ability to use some more
buzzwords). The level of protection is just the same of a
Unix file with the right permissions.
The key point here is that both the 'postgres' user and
'administrator'
--- Marco Colombo [EMAIL PROTECTED] wrote:
As long as the 'postgres' user has access to it w/o
typing any password,
that's only a detail. Unless someone physically
steals your disk, the
fact it's stored encrypted is irrelevant. The only
thing that matters is
who can access it, and how.
Hi Magnus,
You are right. My description is based on windows 2000
which is the weakest one.
Have the recovery key only available off-line is a
good practice. And if you don't want recovery agent,
backup the user's private key is also appropriate. It
can be done without effort. You don't need an
On Thu, 2005-06-09 at 13:54 +0200, Magnus Hagander wrote:
The EFS encryption as you described it adds nothing but a
false sense of security (and the ability to use some more
buzzwords). The level of protection is just the same of a
Unix file with the right permissions.
The key point
The EFS encryption as you described it adds nothing but a false
sense of security (and the ability to use some more
buzzwords). The
level of protection is just the same of a Unix file with
the right
permissions.
The key point here is that both the 'postgres' user and
I don't know, I just tested it on win32.
Changyu
--- Magnus Hagander [EMAIL PROTECTED] wrote:
(BTW, am I correct in reading this as a problem that
only appears on
win32, because of the exec nature of the backend,
right? Or does it show
up on Unix as well?)
//Magnus
On Thu, 2005-06-09 at 05:21 -0700, Changyu Dong wrote:
--- Marco Colombo [EMAIL PROTECTED] wrote:
As long as the 'postgres' user has access to it w/o
typing any password,
that's only a detail. Unless someone physically
steals your disk, the
fact it's stored encrypted is irrelevant.
On Thu, 2005-06-09 at 15:04 +0200, Magnus Hagander wrote:
[...]
Yes, that is correct - runas is similar to su. But in order to do
runas, you need the service accounts password. Once you are root on
a unix system, you can do su - user *without* the password. That's a
big difference.
(You can
Yes, that is correct - runas is similar to su. But in order to do
runas, you need the service accounts password. Once you
are root
on a unix system, you can do su - user *without* the password.
That's a big difference.
(You can also use the postgres accounts smartcard, if you are
--- Marco Colombo [EMAIL PROTECTED] wrote:
Either the Windows backup contains the private key
of the user or not.
If not, the backup is incomplete and useless (to get
the file contents).
You may get other files from it, but that's not the
point. You may just
not include the key file in
Hi,
I¡¯m using postgreSQL with SSL these days. The version
I¡¯m using is 8.0.3. I found that it¡¯s impossible to
use an encrypted key file.
When you use a protected server.key file, you will be
prompted to input your passphrase EVERYTIME IT¡¯S
USED, not only when you start the server but also
Hi,
I¡¯m using postgreSQL with SSL these days. The version I¡¯m
using is 8.0.3. I found that it¡¯s impossible to use an
encrypted key file.
When you use a protected server.key file, you will be
prompted to input your passphrase EVERYTIME IT¡¯S USED, not
only when you start the server
Greetings!
Does anybody know how well the optimizer works when dealing with inherited
tables? I am currently using 8.0.1.
I have a table called eventlog.record_main, and a number of inherited
tables to partition the data (called
eventlog_partition._day__record_main). luid is the primary key (all
On Wed, 2005-06-08 at 16:08 +0200, Magnus Hagander wrote:
Hi,
Im using postgreSQL with SSL these days. The version Im
using is 8.0.3. I found that its impossible to use an
encrypted key file.
When you use a protected server.key file, you will be
prompted to input your passphrase
Hi,
A possible countermeasure on Windows platform,
inspired by Magnus.Thanks ;)
First we remove the passphrase from the key file,
making it plain.
Windows provides a feature encrypted file system,
provide transparent encryption/decryption. We can log
on using the account we run Postgres with and
18 matches
Mail list logo