Какой-то странный вопрос. Root всегда может ВСЕ, в пределах
своей системы или это не root.
И нифига ты ему не запретишь.
Postgres - тоже может все в пределах базы.... То что лежит в
каталоге ./usr/local/pgsql/data - все доступно ему.
А если ты не доверяешь почему-то ни тому ни другому... например
если ты хостишь базу на чужом серваке - криптуй данные на клиенте
и ложи их криптованными на сервак. Можно это делать и на серваке и это
даже правильней.... только надо помнить что рут может при сильном желании
и tcpdump поюзать так что придется возиться и с ssl.
Штатных средств для криптования самой базы в Постгресе нет небыло и похоже не будет.
Если сервак твой, и ты опасаешься что при физическом доступе (сперев например винт) кто-то заделается рутом итд..... ставь файловую систему с криптованием, я в них ни уха ни рыла да и тут вопрос вообще уходит в оффтоп полнейший. 8)
Кстати я кажется уже писал по схожему поводу что шифрование данных включая структуру баз - достоинство оччень немногих серверов и большинство
- коммерческие. Из свободных это умел кажется SAP DB а может и нет.

2All:
update customers set
fname='D4S*#d3r4t92!h@f4ewэыуs'
comment='df93-4t094hfg4bg3g39d0c40opkfsdf'
where id=@ssd3dfdff;
Что касаемо select-ов :
create view customers as
select @@fname,@@phones, @@comment,@!lastbarg
from _customers
where
@@fname ~~'%Вася%'
and phone ~~'%2124510%'
Осталось только пара замечаний:
--Структуру базы мне прятать нет надобности.
--ssl - классная штука Читайте ./pgsql/doc/ssl-tcp.html
--Пользовательские операторы тоже прикольная штука!

Причем тут "=" ? *)
Безразлично какая операция - расшифрованные данные выдает оператор @@
Что касаемо выборок вот например
select @@cur_event from evh_tod where (@@edate >'20.09.2003'')and (@@edate <now() )
Ключ сервер получает от клиента по ssl. Как он выглядит где и сколько он хранится - это уже мое ноу-хау.
И особо подчеркну - потери производительности при такой шифровке ОЧЕНЬ БОЛЬШИЕ. Любая файловая система с криптованием даст выигрыш раза в два.
А вообще в каждом конкретном случаем приходиться изобретать свой велосипед.... А если кому-то влом - юзайте Оракл/MS SQL - там наверняка за
пару килобаксов чегото предложат. 8)

Вопрос странный именно потому что я никогда не ждал от свободных серверов мощных защитных средств.
Их ИМХО никто там реализовывать пока и не будет. Потребность не созрела.
А ключ который хранится на серевере - он для ШИФРОВАНИЯ..... И он доступен всем.
Пользователи таскают на картисах ( похаченные проездные для метро ;) , благо один знакомый железячник помог с ридерами шаровыми и добыл доку на драйвер. Карточки кстати заинтересованные люди уже копировали на пробу - получили клевый облом. Компакт оттиражировать обычно проще :)
Остальное описано в соотв литературе в 1978 году.
. RTMF RSA/DES datasheet до просветления, ибо дао описанное в открытом форуме не есть дао 8)
Все. Это форум не по защитам и криптосистемам а я не бесплатный консультант по защитам да и не спец в криптографии. То что мы делали делалось для конкретной задачи коммерческой структуры это не панацея и
не Express Course for impatent
Так что тему я считаю закрытой
Резюме:
-Защиты данных в Постгресе нет.
-Сделать ее самому нельзя (спасибо leningard за понимание) Ж:) !
-Вывод : если хочешь крутую защиту данных - пользуйтесь СУБД "Линтер" http://www.relex.ru/rus/index.php

Ой как много эмоций.... Ну подумайте какая "безопастность" и "защита" по
на этом свете? Круче всего спрятан/зашифрован файл который ты прописал нулями. ;)
А вообще-то есть возможность не хранить
на сервере ключи для дешифровки. Это так же глупо как класть их под коврик ;) Клиент с ключами приходит и уходит НО если кто-то от рута будет
сидеть на сервере и снимет (чем-ни-будь-вроде-tcpdump) "слепок" ключа - пиши пропало... и не нужно снимать винт -
это ничего вообщето и не даст. Главное - перехватить ключ -
это возможно в двух точках. Канал под SSL я за неимением реальных примеров взлома считаю надежным. Остаются клиент и сам сервер -
получив дамп проходивших в момент авторизации пакетов можно получить и ключ.
Вот и все - схема защиты примитивна.
Реализация - возможна. Взлом возможен и достаточно дорог что бы
спать спокойно. Кстати я забыл упосянуть что при удачном падении в postmastera в core можно теоретически отловить ключ правда сделать
без рута на серваке это пока проблематично.... дырки позоволявшие
валить серваки 7.0.-7.1 не особо широко известны да и большинство исправлено. Вывод - ну унес винт - воюй с ним на здоровьечко. Если пофартит и запуститься процедура дешифровки (а она вообщето любит работать только на родном сервере и отдебажить ее будет похоже проблематично) - масса возможностей для bruteforce.
Ломай - подбирай-жди....
Ух утомила меня эта проза..... Может кто-то менее ленивый расскажет
Leningrad как пользоваться RSA+DES? Я просто не могу припомнить урл
подходящий.....

Смотрим тут /usr/ports/security/cfs
Читаем pkg-comment:
A cryptographic file system implemented as a user-space NFS server
Это почти тоже самое что делаешь ты только чуть глобальней.
Неудобство одно - при ребуте и монтировании раздела нужно будет
указать пароль. Неудобно? Зато секьюрно 8>
Зато весь каталог data лежит криптованный и скорость падает незначительно.
Например на PII-233 задержка отклика уже почти незаметна.
А дамп криптовать а потом базу дропать..... дюже геморойно.....
К тому же насколько я понял про pg_resetxlog t ты небось забыл а ведь в WAL -логе может проскочить интересная инфа 8)
А обрезание WAL-лога тоже времени требует....
ИМХО CFS как решение круче и проще будет.