cygwin sftp chroot не может просматривать содержимое связанной точки монтирования
Я пытаюсь дать user2 доступ только к его домашнему каталогу и полные разрешения на /cygdrive/e. Я создал Data/ каталог в его $home, добавил bind директива в /etc/fstab (см. ниже) и выпустил mount -a.
У меня установлен cygwin и запущен sshd (OpenSSH_6.1p1). При соединении с ChrootDirectory включен в подсистеме sftp, ~/Data похоже, не имеет содержимого. Даже если я изменю разрешения для /cygdrive/e рекурсивно к 0777, результат тот же. С участием ChrootDirectory активен для этого пользователя в sshd_config, содержимое не отображается.
Однако при подключении с использованием той же учетной записи пользователя без изменения разрешений содержимое ~/Data полностью заполняется после того, как я закомментирую Subsystem раздел внизу sshd_config и перезапустите sshd.
Итак, как я могу предоставить этой кошке разрешение в режиме бога на /cygdrive/e не давая ему возможности просматривать любую другую часть файловой системы? Что мне не хватает?
Дно моего sshd_config как следует:
Subsystem sftp internal-sftp
Match User user2
ChrootDirectory /home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
Единственная строка в /etc/fstab гласит:
/cygdrive/e /home/user2/Data none bind,posix=0,user
В настоящее время рекурсивное владение /cygdrive/e принадлежит Administrators:Users. В user2 Учетная запись Windows является членом Users так же как Administrators. Все каталоги имеют маску 0755. Все файлы имеют маску 0644.
Я не без ума от user2 имея права администратора на машине, но я займусь этим позже. По одной проблеме за раз.
Ответ
К сожалению, это невозможно. Многие элементы сговариваются, чтобы победить вас на каждом шагу.
Почему бы не создать точку монтирования внутри тюрьмы?
По-видимому mount в cygwin ведет себя совершенно иначе, чем в операционной системе POSIX. В cygwin mount ограничивается областью текущего сеанса, вошедшего в систему. Это означает, что если вы смонтируете устройство как user1, затем user2 не будет доступно это крепление.
Не имеет значения, какой тип крепления bind, более традиционный ntfsкрепление типа, или cifs сетевой ресурс. Никакая привязка не является постоянной. Даже если ты mount --change-cygdrive-prefix /path/to/jail, пользователи sftp не увидят его, да и другие привилегированные пользователи.
Хорошо, тогда почему бы не поместить тюрьму в / cygdrive / e?
После того, как клиентское соединение sftp установлено, /cygdrive/e еще не существует. Даже если это так, есть еще одна проблема. Помните, что каждый каталог от корня до кормы /path/to/jail должен принадлежать root. поскольку /cygdrive монтируется во время выполнения для сеанса пользователя, владелец /cygdrive текущий пользователь. И chown root:whatever /cygdrive ничего не делает - ошибки нет, но и эффекта нет.
А как насчет решения хост-ОС? Будет ли работать жесткая ссылка Windows или переход?
К сожалению, с точки зрения взаимодействия с клиентами, mklink это просто причудливый способ создания ярлыков. Не имеет значения, создаете ли вы символическую ссылку на файл или каталог, жесткую ссылку или соединение. Клиент sftp видит их все как просто значки со стрелкой mklink не вводит в заблуждение sftp-клиента его особенным методом обмана.
Принятие поражения
Просто нет возможности научить internal-sftp chroot, чтобы понять неловкую имитацию Cygwin mount. Другие пытались, но даже эксперты сбиты с толку.
Что ж, тогда не используйте internal-sftp. Создайте сценарий оболочки для выполнения монтирования при подключении.
Это могло быть возможно. Я не пробовал, потому что там кажется непростым способом для оболочки, чтобы отличать привилегированного пользователя от пользователя, заключенного в chroot-тюрьму, и я все еще хочу иметь возможность просматривать всю файловую систему с моей собственной учетной записью. Кроме того, установка полной среды chroot-тюрьмы оскорбляет мое тонкое чувство эстетической привлекательности. Я бы предпочел, чтобы у вошедшего в систему пользователя было меньше мест, где можно потеряться. Я предпочитаю низкое соотношение мусора и контента, если это имеет смысл.
Так что ты собираешься делать?
На моем ПК с Windows я предоставил доступ к папкам, которые мне нужны для sftp. На небольшом ПК с Linux я сопоставил соответствующие общие ресурсы cifs через autofs, а также настройка с задержкой mount bindфайлов в fstab, каталоги привязки в autofs монтируется в точки монтирования в пределах internal-sftp chroot jail. Работает потрясающе! Клиент подключается к моему устройству Linux для загрузки / загрузки файлов в мои общие папки Windows. Для пользователя все полностью прозрачно. Для меня установка терпима к перезагрузкам и не требует беспокойства.
Возможно, это будет хорошим предлогом для любого, кто в подобной ситуации, получить Raspberry Pi или какой-либо ПК с подключаемым модулем и сделать то же самое.