Re: BUG #5275: validate_exec in port/exec.c only reads u/g/o, not ACLs
От | Tom Lane |
---|---|
Тема | Re: BUG #5275: validate_exec in port/exec.c only reads u/g/o, not ACLs |
Дата | |
Msg-id | 4178.1263417713@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #5275: validate_exec in port/exec.c only reads u/g/o, not ACLs ("James Bellinger" <jfb@zer7.com>) |
Ответы |
Re: BUG #5275: validate_exec in port/exec.c only reads
u/g/o, not ACLs
|
Список | pgsql-bugs |
"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? regards, tom lane
В списке pgsql-bugs по дате отправления: