Re: unprivileged user

Поиск
Список
Период
Сортировка
Искать
От
Andrew Dunstan
Тема
Re: unprivileged user
Дата
Msg-id
4B217416.4000008@dunslane.net
Ответ на
Список
Дерево обсуждения
unprivileged user Andrew Dunstan <andrew@dunslane.net>
Re: unprivileged user Tom Lane <tgl@sss.pgh.pa.us>
Re: unprivileged user Andrew Dunstan <andrew@dunslane.net>
Re: unprivileged user Peter Eisentraut <peter_e@gmx.net>
Re: unprivileged user Andrew Dunstan <andrew@dunslane.net>


Tom Lane wrote:
> Andrew Dunstan  writes:
>   
>> The other day I returned idly to thinking about some work I did a few 
>> years ago on creating a totally unprivileged user, i.e. one with not 
>> even public permissions.
>>     
>
> And the point would be what exactly?
>
> 			
>   

Well, when I was looking at it originally it was in the context of a 
layered security setup, where we wanted to minimise the danger from a 
client machine (say a web server) being subverted. The reasoning was 
that if the subverted user had no access to the database layout, but had 
only access to a very tightly defined set of stored functions, it would 
be harder to devise attacks against the database. It might be argued 
that this is security by obscurity, but obscurity does have some uses, 
albeit never as a complete security mechanism.

Some time later it came up again, this time when someone wanted to use a 
readonly database (hence no pg_dump required) with an application and 
wanted to keep the database layout and the source code of stored 
functions hidden as they regarded it as proprietary information.

cheers

andrew



В списке pgsql-hackers по дате отправления
От: Tom Lane
Дата:
От: David P. Quigley
Дата:
FAQ