Re: BUG #5275: validate_exec in port/exec.c only reads u/g/o, not ACLs

Tom Lane wrote:
> "James Bellinger" <jfb(at)zer7(dot)com> writes:
> > I'm not certain of the actual *purpose* for this function even checking in
> > the first place, but the result is that, if Postgres gets its access via an
> > ACL, it will say 'invalid binary' here and there, will not be able to find
> > its own executables, etc. I can see no purpose for this function.
>
> Hmm. I wonder why we have all that complexity at all, rather than using
> access(2). The man page says it checks against real not effective uid,
> but since we don't run setuid I think there's no difference.
>
> [ pokes in CVS history ... ] Oh, this is interesting: this code looks
> like this clear back to the original Berkeley import, and back then it
> had this comment:
>
> * We use the effective uid here because the backend will not have
> * executed setuid() by the time it calls this routine.
>
> So once upon a time there was a reason to try to implement access()
> for ourselves, but it's long gone. Comments?

I am not sure of its purpose either. I remember having to call it in
the old postmaster code before /port was added, but again, I am not sure
why we didn't use access().

I think access's reputation as something to avoid caused us not to look
at it. My old BSD manual says about access():

CAVEAT
The access() function should be used rarely, if ever. Specifically,
access() should never be used by any program whose user real and effec-
tive IDs, or group real and effective IDs, differ. At best, using
access() in this situation can produce a misleading result, because the
system call permission checks are based on effective IDs. Thus, access()
might return that the file is accessible, when the corresponding open(2)
or exec(2) call would fail, or vice-versa. In addition, the permissions
on the file, or the path leading to the file, may change between the time
access() makes its test and the eventual system call. This timing race
applies to all uses of access(), so it is better to attempt the operation
itself to see if it will succeed. (Processes designed to run setuid or
setgid should call seteuid(2) or setegid(2) as needed to suspend their
special privileges.)

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +