Simon Riggs <simon@2ndquadrant.com> writes:
> On Sat, 2005-01-08 at 12:44 -0500, Tom Lane wrote:
>> I notice that several uses of getuid() have snuck into the code, mostly
>> in relatively-recently-added SSL code. I assert that these all are
>> wrong and should be checking geteuid(). Is anyone going to complain
>> that we need an RC5 to change this?
> No, but increased security is only possible via increased transparency.
It's not a security issue, it's just a correctness issue.
In the backend there's really no difference, since main.c refuses to
start if getuid() != geteuid(); but we should be consistent and the
agreed-on convention is to use geteuid().
In libpq there definitely could be a difference, since libpq could be
used by a setuid program. But what libpq uses it for is to check that
files such as ~/.pgpass are only readable by the current user. Now when
we attempt to open .pgpass, what the OS is going to check is that file
owner == geteuid(); if we reject files that don't belong to getuid()
then we have essentially broken the .pgpass mechanism for setuid
programs.
(It is significant in this regard that we now find the home directory via
geteuid's /etc/passwd entry, rather than trusting $HOME. With the $HOME
approach, .pgpass was probably broken for setuid programs anyway.)
regards, tom lane