Имеет ли право владение файловой системой пользователем без полномочий root какие-либо последствия для безопасности?
Например, каталог /var/lib/pgsql/9.0/data и его содержимое должно принадлежать пользователю postgres. Если я хочу разместить его содержимое в собственной файловой системе, рекомендуется ли
/var/lib/pgsql/9.0/dataили
/mnt/pgsql_data), смонтируйте туда файловую систему, создайте в этой файловой системе каталог, принадлежащий postgres (например, /mnt/pgsql_data/data) и сделать /var/lib/pgsql/9.0/data символическая ссылка на этот каталогЕдинственная потенциальная проблема безопасности, которую я вижу в первом случае, заключается в том, что он дает пользователю postgres возможность изменять lost+found каталог (если это файловая система ext2, ext3 или ext4), но я не думаю, что это имеет серьезные последствия.
Что побудило меня задать этот вопрос, так это то, что создание базы данных postgres не поддерживается, если файловая система смонтирована в каталоге данных; видеть это обсуждение pgsql-hackers. Раньше я не рассматривал первый пункт этого поста.
Я не осведомлен о каких-либо реальных последствиях для безопасности. Я думаю, что ключевым моментом является то, что монтирование linux полностью заменяет то, что уже есть в каталоге (ну, если вы не выполняете объединенное монтирование, но это другая тема).
Для простоты и условности я бы просто сделал data каталог, принадлежащий пользователю root, и выполните монтирование в нем.
Зависит от файловой системы. Насколько мне известно, ext3, например, не распознает uid владельца точки монтирования, а только uid корня смонтированного раздела.
В любом случае представьте, что вы используете какую-то хромую файловую систему, которая будет уважать право собственности и следовать за мной ...
В зависимости от иерархии и содержимого файловой системы могут возникнуть серьезные проблемы с безопасностью.
Позвольте мне проиллюстрировать это (извиняюсь за степень художественной свободы, но я не буду рассматривать возможные проблемы с блокировкой файлов ... 8D)
#mkdir /opt/postgres
#mount /dev/sdf1 /opt/postgres
#chown postgres:portgres /opt/postgres
#ls - /opt/postgres/8.3/
drwxr-xr-x 4 postgres postgres 1024 2011-08-11 23:14 .
drwxr-xr-x 7 root root 48 2011-08-11 23:11 ..
drwxr-xr-x 2 root root 1024 2011-08-11 23:14 bin
drwxr-xr-x 2 root root 1024 2011-08-11 23:14 lib
drwxr-xr-x 2 root root 1024 2011-08-11 23:14 doc
drwxr-xr-x 2 root root 1024 2011-08-11 23:14 contrib
drwx------ 2 root root 12288 2011-08-11 23:13 lost+found
теперь предположим, что кто-то имеет доступ к postgres и хочет выполнить бэкдор /opt/postgres/8.3/bin/createdb
$cd /opt/postgres
$cp -R 8.3 .hackme
$cd .hackme/bin
$echo 'rm -rf /' > createdb
$cd ..
$mv 8.3 .old; mv .hackme 8.3
Подобные атаки на повышение привилегий являются устаревшими ... В прошлом варианты были довольно распространены. Я должен добавить, что такой ошибочный подход является одной из основных причин, по которой стандартная рекомендация состоит в том, чтобы файлы конфигурации (например, httpd.conf) принадлежали пользователю, а не тому, который используется процессом.
Надеюсь, поможет