Какова цель настроек по умолчанию / etc / securetty в Debian?

Я создал нестабильный контейнер Debian с debootstrap и запускал его с помощью systemd-nspawn.service .

Я могу войти в систему под root с именем пользователя machinectl login , но не более одного раза в одно и то же время. Когда я запускаю второй логин, он отказывается, как только я вхожу в root ; он не запрашивает пароль.

Как вы могли ожидать, если я посмотрю на системный журнал, он говорит, что доступ запрещен pam_securetty потому что tty /dev/pts/2 "небезопасно". Это вызывает несколько вопросов.

  1. как первый login /dev/pts/0 считается безопасным?
  2. почему /dev/pts/1 не используется во втором логине?
  3. По умолчанию / etc / securetty, похоже, перечисляет все типы tty – включая последовательные линии, которые могут быть подключены к модемам? Я могу представить причины исключения псевдотерминалов. Но, если вы собираетесь разрешить все типы физических терминалов, в чем смысл этого упражнения ?! Почему бы не работать с (коротким) набором типов tty, которые не разрешены для входа в систему как root? Есть ли что-либо, что было преднамеренно опущено из списка, которое должно быть заблокировано по умолчанию, кроме псевдотерминалов? Если есть преднамеренное упущение, то почему он не комментирует ???

Я смог ответить Q1. Неописуемо ужасный ответ заключается в том, что в Debian stretch (9-тестирование, login-4.4-4 ) / etc / securetty содержит / dev / pts / 0 и / dev / pts / 1, но не / dev / pts / 2. Можно догадаться, что это было добавлено специально для поддержки systemd-nspawn . И было бы правильно . Но это только меня смущает насчет того, что эти настройки должны выполнить!

Импликация настроек не имеет никакого смысла.

Очевидно, что дистрибутив, поддерживающий последовательные установки, хотел бы иметь возможность разрешить первую последовательную консоль. Ваш вопрос заключается в том, почему первоначальный разработчик Debian считал полезным оставить pam_securetty включенным, но настроить его, чтобы разрешить все типы tty. И, следовательно, что помешало бы распространению от использования более простой установки.

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

https://github.com/systemd/systemd/issues/852#issuecomment-127759667

Это происходит от времени, когда имена tty статичны. Но сегодня наименьшие tty представляют собой старые старые старые серийные порты. Практически все они вместо этого подключены через USB или являются псевдо-ttys. В любом случае, их имена не фиксируются, как ожидает / etc / securetty, вся концепция, следовательно, устарела.

Следовательно: попросите свой дистрибутив прекратить доставку с включенным pam_securetty по умолчанию, это действительно ушло в прошлое. В то же время удалите его вручную из всех файлов в /etc/pam.d/* или добавьте все ваши текущие и будущие ptys в / etc / securetty.


https://github.com/systemd/systemd/issues/852#issuecomment-128564307

Вы можете просто удалить / etc / securetty из контейнера, который разрешит вход root во все tty.