Kevin Hunter <hunteke(at)earlham(dot)edu> writes:
> At 3:50p -0400 on Sat, 29 Mar 2008, Tom Lane wrote:
>> The code appears to want 700 and ownership equal to that of the
>> process executing libpq, ie, the apache server.
> I just checked the 8.3 documentation and didn't see any mention of
> the private key file requirements. Modulo the fact that I don't know
> the docs /that/ well, would a HINT be helpful here? Or a pointer to
> the correct doc section?
Hmm. The quality of the error message does seem to be fairly far short
of what we expect for user-facing messages. We've got this:
if (!S_ISREG(buf.st_mode) || (buf.st_mode & 0077) ||
buf.st_uid != geteuid())
libpq_gettext("private key file \"%s\" has wrong permissions\n"),
versus this coding in the exactly parallel place on the backend side:
if (!S_ISREG(buf.st_mode) || (buf.st_mode & (S_IRWXG | S_IRWXO)) ||
buf.st_uid != geteuid())
errmsg("unsafe permissions on private key file \"%s\"",
errdetail("File must be owned by the database user and must have no permissions for \"group\" or \"other\".")));
Now libpq doesn't have any provision for DETAIL or HINT in its
locally-generated messages at the moment, so we can't just duplicate
the backend message, but we could do something like this example
from elsewhere in libpq:
if (stat_buf.st_mode & (S_IRWXG | S_IRWXO))
libpq_gettext("WARNING: password file \"%s\" has world or group read access; permission should be u=rw (0600)\n"),
I also wonder why we are bothering with explicit tests of the file
ownership in these places. If it's mode 700 or less, and not owned by
us, the subsequent attempt to read the file will fail anyway, no?
That would give us two different failure messages (the explicit one
versus "open failed: permission denied") for the two separate cases.
That seems better than one error message covering two types of mistake.
Lastly, I see that the libpq docs don't cover this very well:
says "The private key file must not be world-readable." which is
true but fails to mention that it also mustn't be world-writable,
world-executable, group-readable, group-writable, or group-executable.
Barring objections I'll go make this nicer in HEAD. Back-patching
is probably inappropriate because it'd change translated strings.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Douglas McNaught||Date: 2008-03-30 21:37:43|
|Subject: Re: Submission of Feature Request : RFC- for Implementing Transparent Data Encryption in Postgres|
|Previous:||From: Tom Lane||Date: 2008-03-30 21:09:17|
|Subject: Re: first time hacker ;) messing with prepared statements |
pgsql-general by date
|Next:||From: Ross Boylan||Date: 2008-03-30 21:43:26|
|Subject: Re: database 1.2G, pg_dump 73M?!|
|Previous:||From: Vismaster46||Date: 2008-03-30 21:12:37|
|Subject: PostgreSQL and Java on WindowsXP|