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

Tom Lane wrote:
> "James Bellinger" <jfb@zer7.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@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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