"James Bellinger" <j...@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?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
