On Thu, 2005-06-09 at 15:53 +0200, Magnus Hagander wrote:
[...]
> > > I guess we could read in the password ourselves and drop it in our
> > > shared memory segment to pass to subprocesses - though that
> > means they
> > > can get to the password easier as well. Assuming OpenSSL
> > has the AP
--- 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
> > 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 smartcar
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.
>
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 i
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
>
> > > 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' u
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 ke
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 arm
--- 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
> 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
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 clien
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 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 encryption/
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
On Wed, 2005-06-08 at 16:08 +0200, Magnus Hagander wrote:
> > 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 y
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.___record_main). is the primary key (all
tables
> 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 se
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 when
19 matches
Mail list logo
