Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "James Bellinger" <jfb(at)zer7(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5275: validate_exec in port/exec.c only reads u/g/o, not ACLs
Date: 2010-01-13 21:21:53
Message-ID: 4178.1263417713@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
"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?

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: Charles O'FarrellDate: 2010-01-13 22:20:16
Subject: Re: Substring auto trim
Previous:From: James BellingerDate: 2010-01-13 20:58:38
Subject: BUG #5275: validate_exec in port/exec.c only reads u/g/o, not ACLs

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group