Разграничение прав доступа виртуальных пользователей PROFTPd

Разработчик сайта /home/http/site1 заливает на свой сайт вирус

Как минимум chroot (из которого при определенном умении можно выйти), оптимум - контейнеры.

оптимум - контейнеры.

Можешь пжл подсказать, в какую сторону смотреть по поводу контейнеров на CentOS (я не знаком с этим вообще)

lxc-docker, чистый LXC, OpenVZ (только на CentOS 6 де-факто нативно с vz-шным ядром).

Спасибо.

только на CentOS 6 де-факто нативно с vz-шным ядром

т.е. только на чистую систему?

Openvz - желательно с ноля ставить.

Остальное - можно и начисто

Добавить ещё одного пользователя!

Я правильно понимаю, что для контейнерной виртуализации:

1. Необходимо разворачивать контейнерную виртуализацию на пустой OS, когда там еще ничего не стоит?

2. Для каждого контейнера необходимо отдельно устанавливать все пакеты (например php, mysql, apache), либо установить вначале все необходимые пакеты в один контейнер, а потом клонировать его?

3. Какую лучше контейнерную виртуализацию выбрать: LXC или OpenVZ с учетом того, что основное направление сервера - это веб-сервер и почтового-сервер с возможностью разграничения пользователей?

p.s: Приходит понимание, что на самом деле, если речь идет о многопользовательской системе и 100% разделении прав пользователей, без виртуализации не обойтись - как не печально (((

Добавить ещё одного пользователя!

и этот пользователь так-же сможет ходить по системе, просматривать конфиги, включая и все то, что лежит в каталоге соседа-веб-разработчика?

как вариант перейти на nginx+php-fpm, тогда можно запускать каждый сайт под отдельной учеткой

как вариант перейти на nginx+php-fpm

многие движки требуют обязательно апачевский rewrite

+

вопрос-утверждение: при контейнерной виртуализации можно сделать, чтобы отдельной учетке нельзя было просматривать содержимое /etc?

вопрос-утверждение: при контейнерной виртуализации можно сделать, чтобы отдельной учетке нельзя было просматривать содержимое /etc?

у тебя в контейнере будет по сути отдельный экземпляр системы, которая с основной делит только ядро. К /etc основной системы доступа там конечно не будет

у тебя в контейнере будет по сути отдельный экземпляр системы

и на каждый отдельный экземпляр системы необходимо будет устанавливать ПО? Т.е. в моем случае, мне нужно всего лишь, чтобы веб-разработчик_1 не мог просматривать директорию веб-разработчика_2, а веб-разработчик_2 не мог просматривать директорию веб-разработчика_1, плюс оба не могли смотреть в /etc, где конфигурационные файлы почтового-сервера, но при этом у обоих одно и то же ПО (например apache+nginx+mysql+php) и настройки для этого ПО должны быть одинаковыми для обоих, как в этом случае делается в плане установки и конфигурации ПО?

представь что у тебя два сервера вместо одного. Представил? Вот примерно так у тебя и будет

И я в очередной раз не вижу смысла скрывать /etc. Те места где лежат пароли и так доступны только руту, а конфиги скрывать вообще странная затея

представь что у тебя два сервера вместо одного

это больше похоже на полную виртуализацию.

а в чем тогда смысл контейнерной виртуализации?

смысл в том, что ядро одно на всех, а значит накладных расходов меньше, но и ограничения тоже есть. С определенной точки зрения контейнер это очень продвинутый chroot

Мне просто нужно как в первом посте описал чтобы веб-разработчик_1 не мог смотреть в директорию веб-разработчик_2, а веб-разработчик_2 не мог смотреть в директорию веб-разработчик_1, уже не беру /etc/.

Но nginx+apache+php+mysql - общее ПО с одними и теми же настройками и apache - владелец и у директории /home/http/site1 и у директории /home/http/site2, иначе apache не сможет с ними работать и proftpd от учетки apache запускается, иначе виртуальные пользователи proftpd не смогут получить доступ к /home/http/site1 и /home/http/site2

как сделать в конечном итоге правильно сделать?

попробуй apache2-mpm-itk

попробуй apache2-mpm-itk

сейчас попробую, спасибо.

Все равно дыра остается, а именно: Так как для корректной работы сайтов необходимо на все директории сайтов поставить права 755, а на все файлы 644,то посредством PHP Веб-разработчик_1 может просмотреть каталоги и файлы site2, а Веб-разработчик_2 может просмотреть каталоги и файлы site1.

Здесь конечно выходом может стать - поставить права 440 на конфигурационные файлы сайтов и забить на эту ситуацию, но думаю это как минимум плохое решение.

Так-же все равное мне не дает покоя, что любой веб-разработчик может спокойно гулять по всем папкам и файлам системы, вплоть до конрня, т.е. я например делаю в любом скрипте одного из сайтов так:

readfile(«/etc/passwd»);

и вижу в браузере содержание данного файла. Так-же можно было на виртуальных хостах сделать так:

php_admin_value open_basedir «/home/http/site1» 
php_admin_value open_basedir «/home/http/site2»

и тем самым запретить выходить PHP за пределы корневой директории сайта, но тут другая проблема - практически все известные PHP-движки начинают работать некорректно при этом и испытывать проблемы, вообщем этот вариант отпадает.

Млинский млин, что еще можно сделать?