Re: Is PQfn() insecure or not?
От | Tom Lane |
---|---|
Тема | Re: Is PQfn() insecure or not? |
Дата | |
Msg-id | 7477.1041448969@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Is PQfn() insecure or not? (ljb <lbayuk@mindspring.com>) |
Список | pgsql-interfaces |
ljb <lbayuk@mindspring.com> writes: > "Programmer's Guide, Client Interfaces, libpq, The Fast-Path Interface" > describes PQfn() and has this alarming remark: > "This is a trapdoor into system internals and can be a potential > security hole." > Sure this isn't true. PQfn() just lets a frontend call a function which is > also accessible (if maybe not useful) via a SELECT statement, correct? The insecure part is not the function call per se (*); it's the fact that the frontend feeds raw internal-format values to the backend for the function's parameters. It'd be fairly trivial to cause a backend crash by feeding bogus data. Not sure whether it's possible to do anything worse than that. One thing we should think about during the planned protocol redesign for 7.4 is whether to change fastpath to pass and return external-format values. This would slow it down marginally, but would make it far safer and more convenient to use ... (*) Actually, I just noticed that the fastpath code fails to check whether the user has permission to call this function, so as of 7.3 that could be considered a security hole. It's an easily fixable one, though. regards, tom lane
В списке pgsql-interfaces по дате отправления: