`crontab -e`« разрушает »терминал

. На самом деле не имеет значения, находятся ли файлы в / bin (или в любом другом стандартном каталоге, где исполняемые файлы сохраняются) доступны для записи root или нет. На сервере Linux, который я использую, они доступны для записи от root, но на моем компьютере с OpenBSD это не так.

Пока они не доступны для записи группе или «другим»!

Нет проблем с безопасностью, например,

-rwxr-xr-x 1 root root 126584 Feb 18  2016 /bin/ls

Если кто-то хочет перезаписать его, он должен быть пользователем root, а если он root и перезаписывает его, то он либо

  1. устанавливает новую версию, либо
  2. неуклюже или
  3. злоумышленник с уже имеющимися правами root .

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

Также обратите внимание, что «сценарий» - это в такой же степени исполняемый файл, как и двоичный файл. Сценарий не обязательно должен быть доступен для записи, «потому что это текстовый файл». Во всяком случае, он, вероятно, должен иметь те же права, что и другие исполняемые файлы в том же каталоге.

Не меняйте сейчас разрешения для всего! Это может вызвать разного рода хаос и потенциально сбить с толку менеджеров пакетов, которые могут проверять правильность установки разрешений. Это также может сделать систему уязвимой, если вы случайно неверно измените разрешения для критически важного с точки зрения безопасности приложения.

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


Из комментариев и в чате прозвучал призыв к истории.

История прав доступа к двоичным файлам в Linux - это то, о чем я ничего не знаю. Можно предположить, что они просто унаследовали разрешения от каталога или просто от стандартной umask Linux, но я действительно не знаю.

Я точно знаю, что OpenBSD устанавливает двоичные файлы в базовой системе 1 с режимом прав доступа 555 по умолчанию ( -r-xr-xr-x ). Это указано во фрагменте файла Makefile в /usr/share/mk/bsd.own.mk , который устанавливает BINMODE на 555 (если он еще не установлен). Позже это используется при установке исполняемых файлов во время make build в / usr / src .

Я просмотрел аннотированный журнал CVS для этого файла и обнаружил, что эта строка в файле не изменилась, так как она была импортирована из NetBSD в 1995 году.

В NetBSD файл был впервые был помещен в CVS в 1993 году с BINMODE , установленным на 555.

Похоже, что проект FreeBSD использовал тот же файл, что и NetBSD , по крайней мере с 1994 года ], а с более поздней фиксацией добавляет в сообщение фиксации подсказку о том, что старые файлы принадлежали выпуску 4.4BSD Berkeley Software Distribution.

Кроме того, CSRG в Беркли хранила исходники в SCCS , но их репозиторий доступен в форме Git на GitHub 2 . Дело, которое мы даем судебно-медицинской экспертизе здесь , похоже, было совершено Китом Бостиком (или кем-то в непосредственной близости от него) в 1990 году.

Вот и вся эта история. . Если вы хотите узнать , почему , то, полагаю, нам придется спросить Кита. Я как бы надеялся увидеть сообщение фиксации изменения, в котором говорится: « это должно быть 555, потому что ... », но нет.

1 Системы BSD имеют более строгое разделение на «базовую систему» ​​и «пакеты сторонних производителей» (порты / пакеты), чем Linux.Базовая система представляет собой согласованный блок, который предоставляет полный набор средств для запуска операционной системы, в то время как порты или пакеты рассматриваются как «локальное программное обеспечение» и устанавливаются в / usr / local .

2 Также доступен более полный репозиторий GitHub с выпусками Unix, начиная с 70-х годов .

1
21.02.2017, 04:44
1 ответ

OP не ответил на комментарий о сбросе , который должен работать. На снимке экрана показано, что произойдет, если я запустил bash и наберу

stty -onlcr

, чтобы символы новой строки больше не вызывали возврат каретки, а просто превращались в перевод строки для создания эффекта лестницы.

Реконструкция:

breaking and not fixing...

и выполнение сброса:

reset fixes it

В то время как bash сбрасывает некоторые режимы терминала , между командами он, кажется, упускает из виду этот. На странице руководства reset указано, что он выполняет несколько функций, в том числе

включает перевод новой строки

1
27.01.2020, 23:46

Теги

Похожие вопросы