Bond Big (Все сообщения пользователя)

Антон Губарев, копать в сторону хостера. PTR прописывает владелец сетевого сегмента. В большинстве случаев это хостер. У многих хостеров можно это сделать самостоятельно через панель управления, например digitalocean и hetzner это позволяют.

там служебная информация для X-сервера хранится. Если графику на сервере не используешь, то она не нужна.
Права на tmp традиционно 777, можно поменять, но зачем?

Дмитрий Теплухин, rewrite.

Порты в iptables еще надо открыть.  

s909, в справке vsftpd.
Ну или в гугле.

s909, ну, я просто установил:
# yum install vsftpd

и поправил пару параметров в конфиге:
anonymous_enable=NO
nopriv_user=bitrix
chroot_local_user=YES

Потом создал пользователя:
# adduser ftpuser -g600 -o -u600 -d /home/bitrix/ext_www/

параметры -g и -u нужно выставить такие же, как у пользователя bitrix:
# cat /etc/passwd | grep ^bitrix
bitrix:x:600:600::/home/bitrix:/bin/bash

Мне нужен был всего один пользователь с доступом ко всем сайтам и директориям.
Если нужен более гранулированный доступ для нескольких разных пользователей, то лучше использовать виртуальных пользователей ftp. Как это сделать - смотреть в справке.

s909, proftpd точно установился? /etc/proftpd/ есть? Конфиги внутри лежат?

А вообще я лично использую vsftpd, в том числе и на bitrixvm. Работает замечательно.

Боюсь, что приличных вариантов нет. Любая виртуализация в linux потребует манипуляций с ядром, чего лучше избегать на работающем production-сервере.
Проще арендовать новый сервер (если речь про хостинг) и на него перетащить все сайты, уже в среду виртуализации, например proxmox ve.  

Боюсь, что только руками переносить. Но зачем?
Если интересуют оптимизированные конфиги, то можно перенести с установленной BitrixEnv.
Стартовое меню, как по мне, довольно бесполезная штука.  

О каких скриптах битрикса идет речь?

Иван, вот так уже предметнее. Но чтобы хоть как-то успешно воспользоваться указанной, гм, "уязвимостью", пользователь должен знать пароль к mysql.
Тут возможны три сценария:
1) нам необходимо дать кому-то (например, разработчику, который докручивает решение) доступ на все директории сайта. В таком случае он легко читает файлик dbconn.php и получает пароль. Но мы ему и так дадим пароль на mysql и еще и в явном виде разрешим проброс порта в ssh, потому как это необходимо для работы (а некоторые странные люди даже выставляют mysql голой жопой в интернет для таких задач). Даже если мы запретим такому пользователю проброс портов, тунелирование или даже создадим виртуального ftp-пользователя, никто не помешает ему установить web-shell на сайт, который (внимание!) все равно будет работать с правами реального пользователя, от которого запущен апач, в данном случае это пользователь bitrix. Соответсвенно, риск "о господи, пользователь может пробросить порт! Ололо! Алярма!" считаем приемлемым, т.к. никакого повышения прав или несанкционированного доступа к чему-либо, кроме того, к чему и так есть доступ, не происходит. Условно говоря, давая кому-то ключ от входной двери, ты не паришься, сможет ли он открыть форточку.
2) нам необходимо дать кому-то доступ в какую-то конкретную директорию, например с каким-то модулем, для его доработки. Тут пользователь не может посмотреть файл dbconn.php, но в большинстве случаев ему все равно требуется доступ к базе и он его получит. Параноидальные режимы "надо же создать отдельного mysql-пользователя с доступом только в конкретные таблицы!" не рассматриваем. В реальности так никто не делает, практически никогда. Слишком невыгодное соотношение трудозатраты/безопасность.
3) вариация второго, но доступ только в папку с какими-нибудь картинками или еще чем-то подобным, когда нет доступа к директориям, где можно запускать php-файлы на исполнение и, соответственно, веб-шелл не запустить. Что ж, веб-шелла уже и так нет, пароль на mysql мы не сообщаем и узнать его пользователь не может (нет доступа к dbconn.php из-за chroot), остается только возможность пробросить порты и рассылать СПАМ от имени нашего сервера и делать подобные нехорошие штуки. Но т.к. этот пользователь - человек, которого мы нанимаем и, соответственно доверяем в какой-т остепени, а все действия оседают в логах (кто и когда подключался), то вероятность реализации данной уязвимости стремится к нулю. А т.к. риск это (грубо) - функция вероятности реализации угрозы потенциальной уязвимости и итогового влияния на актив, то при вероятности, стремящейся к нулю, риск также стремится к нулю.

Итак, если все же заморочиться оценкой рисков и посчитать ROI трудозатрат на реализацию ftp с виртуальными пользователями vs реализацию простого и быстрого способа (фактически - одна команда в ssh, также одна команда на отключение пользователя, всё, никаких больше телодвижений) способа реализации FTP-доступа, указанного выше, то мы приходим к выводам, что это вполне адекватный задаче способ с приемлемым уровнем риска. Итого, задача решается с минимальными трудозатратами, обеспечивая адекватный результат.
Я лично не вижу смысла (кроме как неиссякаемого перфекционисткого стремления к идеалу) заморачиваться чем-то еще.
Но спасибо за поднятые вопросы, они очень интересны, хорошая получилась беседа, полагаю, что наша беседа пригодится читающим, каждый сделает свои выводы исходя из своих приоритетов и задач.

Иван, это не заблуждение, это man sshd_config
На моем сервере туннель не работает, как ему и положено.

Если это попытка пошутить про терморектальный криптоанализ, то она не в кассу, сорри.  

Иван, любопытные рассуждения. Жаль, что отталкиваются от неверных предпосылок. Директива PermitTunnel в конфиге sshd по умолчанию имеет значение No. И в BitrixEnv оставлено значение по умолчанию. Это нужно залезть и изменить конфиг и не забыть перезапустить ssd демон.
Поэтому все описанные сценарии неосуществимы. Если есть еще идеи возможных угроз - прошу поделиться. Пока я не вижу никаких.

/sbin/nologin решает эту проблему. Доступ по FTP есть, по ssh/sftp - нет. Делаем chroot средствами FTP и всё, пользователь замкнут внутри директории, которую мы ему укажем, хоть папка конкретного модуля, хоть директория сайта целиком.

В данном случае для этого придется запускать демон FTP либо от имени рута, либо от имени bitrix, либо от имени такого же пользователя с id, идентичным пользователю bitrix. Т.е. ничего по сути не меняется, а в первом случае так еще хуже.
Да, есть смысл это делать, если нужно предоставить разный доступ нескольким разным людям. Но если нужно всего одному - то без разницы.

Анна Головко, если есть желание держать в голове еще одну деталь при каждом обновлении - велкам, каждый сам себе выбирает приключения. Я свой вопрос вполне конкретно задал - как решить задачу без корректировок дефолтных, штатных прав на файлы и папки. Решение есть, через штатный механизм OS. Оно является оптимальным во всех смыслах.

Анна Головко, вот об этом и речь. BitrixEnv по неведомым причинам запихивает сайты в папку пользователя, на которую права 700. И либо требуется менять дефолтные права на папку пользователя (что не есть хорошо и неизвестно, как поведет себя скрипт обновления BitrixEnv, не захочет ли восстановить права и все в таком духе), либо создавать пользователя с идентичным UserID. Выше предложено второе и по моему мнению, второе лучше. Тоже не очень, грязновато, но лучше, чем права направо-налево корежить с неизвестными последствиями в будущем.
Так понятнее?

Анна Головко, проблема немного сложнее, чем вам кажется. Что такое права на папку "700" вам известно? В данном случае ключевое значение имеет вторая цифра, которая как раз сообщает, какие права назначены группе, к которой принадлежит владелец папки. И какие же? Правильно - никаких. Доступа нет. И именно об этом я говорил, когда писал "не ломая права на папку".  

Виталий Черепанов, спасибо, помогло!
Магически-шаманско-бубенная часть этой инструкции - создание юзера с айдишником пользователя bitrix. Мне почему-то казалось, что это невозможно (id пользователя должен быть уникален). По крайней мере usermod не дает сменить существующему пользователю id, только удалить и создать заново.

Александр Панишев, и нет никакого workaround'а приличного?  

Андрей, не знаю, как было в 4-й (не пользовался), а вот в пятой все сайты лежат внутри личной папки пользователя bitrix и права на нее только ему предоставлены. И апач запущен от имени bitrix.
Соответственно, дать кому-либо доступ, не "поломав" права на папку /home/bitrix мне не представляется возможным.

Может у кого-то есть идеи, как дать доступ FTP-пользователю в какую-нибудь конкретную папку сайта или же к папке ext_www, например? Не ломая прав на папку /home/bitrix?

Это было сделано, как я писал. Не помогало.

Просвирнов Андрей, ну, "решить" - это громко сказано. Нашел workaround - установил CentOS 6.5, поставил BitrixEnv, обновил CentOS (yum check-update && yum upgrade) до 6.6. В такой последовательности все норм.

А не подскажете, что за панель управления такая интересная? У BitrixVM появилась веб-админка?

Возникла проблема при установке на чистый CentOS 6.6 minimal (x86_64)
делаю ./bitrix-env.sh, получаю в конце:
Пакеты самбы не установлены в системеПробовал предварительно установить samba3 и samba4 (по очереди), но это не помогло.