LINUX.ORG.RU

Вышел Midnight Commander 4.8.22

 ,


0

3

Примерно через полгода после релиза версии 4.8.21 вышел Midnight Commander 4.8.22.

Новое в этой версии:
Ядро:

  • Поддержка операции клонирования файлов BTRFS;
  • Найти файл: показать шаблон и содержимое в заголовке окна результатов;
  • Найти файл: запомнить состояние (пустое или нет) поля «Содержимое»;
  • Улучшена поддержка IBM i;
  • Улучшена обработка ошибок создания жестких ссылок;
  • Поддержка определённых пользователем подсказок в подоболочке Fish;

VFS

  • sftp: поддержка сохранения atime и mtime;

Редактор

  • Очистка man-страницы;
  • Синтаксис:
    • PHP - выделение ключевого слова «null»;
    • Meson - начальная реализация;

Разное

  • ext.d: теперь MPV используется как запасной вариант вместо mplayer'а;
  • ext.d: улучшено распознавание форматов MS Office;
  • Очистка кода;
  • Очистка файлов подсказок;

Устранены такие баги как

  • Не компилируется для Apple;
  • «Невозможно создать целевой файл», когда у цели есть экранированный пробел в имени;
  • Перезапись одного файла без вопросов;
  • Отображать сообщения об ошибках для каждой неустановленной программы при просмотре документов в форматах MS Word и Excel;
  • Сбой при попытках некоторых sftp соединений;
  • Сбой при возврате в файловый менеджер из подоболочки;

>>> Скачать

★★★★★

Проверено: jollheef ()

Ответ на: комментарий от Croco

из-под которого вы имеете привычку повышаться до root'а, эквивалентно получения доступа к root'у.

Нет. Как минимум
1) пользователю могут быть доступны только отдельные команды;
2) в случае рута надо угадать только пароль, а в случае пользователя ещё и пользователя (ну или там пусть ключ стянуть);
3) в случае доступа более, чем одного человека, полезно знать, кто именно лазил в данный конкретный момент.

AS ★★★★★ ()
Ответ на: комментарий от AS

Нет

Да

1) пользователю могут быть доступны только отдельные команды;

С одной стороны, это не есть «повышение полномочий»; с другой — «отдельные команды» имеют тенденцию внезапно оказываться умеющими запускать шелл, или выполнять произвольные внешние команды, или просто оказываются дырявы. Я несколько раз видел в sudoers команды вроде 'vim /etc/hosts', а прописавший это админ обычно вообще не понимает, в чём состоит его косяк, даже если показать.

2) в случае рута надо угадать только пароль, а в случае пользователя ещё и пользователя (ну или там пусть ключ стянуть);

Это вообще не о том. То есть это к рассматриваемому вопросу сугубо ортогонально. Иной вопрос, что имя пользователя не является секретной/охраняемой информацией (ну, обычно это так), и, как следствие, в контексте безопасности следует предполагать, что злоумышленнику не нужно ничего угадывать, он уже и так всё знает. Впрочем, если на то пошло, root'а никто не заставляет называть root'ом.

3) в случае доступа более, чем одного человека, полезно знать, кто именно лазил в данный конкретный момент.

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

С другой стороны, естественно, у каждого администратора должен быть свой root'овый (т.е. с uid==0) аккаунт; с задачей логгинга это прекрасно справляется, как и избавляет от необходимости сообщать друг другу пароль (что делать нельзя никогда от слова совсем).

Croco ()
Ответ на: комментарий от AS

Нет. По всем пунктам принципиальных отличий нет, а удобство есть.

Какое ещё «удобство», речь идёт о фундаментально неверном (я бы даже сказал, вызывающе шапкозакидательском) подходе к безопасности. Ещё раз: если злоумышленник каким-то образом получил доступ к непривилегированной учётке, а из-под этой учётки её владелец имеет вредную привычку становиться root'ом, то для злоумышленника тоже стать рутом — это уже дело техники, причём техники простенькой. С точки зрения безопасности это тупо означает, что root у злоумышленника уже в кармане.

Само по себе это ещё не проблема — если, например, под этой учёткой вообще ничего не делать другого, кроме как сразу же тем или иным способом превращаться в рута, то ага, можно считать, что это такой root, просто требующий дополнительного (ненужного, заметим) телодвижения. Проблемы же появляются в сочетании предыдущего тезиса с тем обстоятельством, что под непривилегированными аккаунтами люди обычно ведут себя гораздо смелее, чем под root'ом — ну, например, X Window гоняют, браузер запускают со всеми его дырами, да мало ли что вообще делают. И думают при этом, что если что, то у них тут под этой учёткой ничего ценного не лежит, можно её, например, снести и новую сделать в крайнем случае, а root якобы защищён паролем. Как узнать этот пароль, если он вводится в сеансе под непривилегированной учёткой, а злодей в ней уже живёт — я несколькими комментами выше написал.

В целом ложное ощущение безопасности само со себе крайне вредно. Если сделать несколько root'ов, то такого ощущения не будет.

Croco ()
Ответ на: комментарий от Croco

Ещё раз: если злоумышленник каким-то образом получил доступ к непривилегированной учётке

Если он получил к непривилегированной, то доступ к привилегированной ему получить не более сложно. И глупо в этом сомневаться: это ровно такие же логин и ключ/пароль.

AS ★★★★★ ()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

Если он получил к непривилегированной, то доступ к привилегированной ему получить не более сложно

Простите, сударь, вы издеваетесь? Или вы не знаете о существовании иных способов получения доступа, нежели подбором пароля? Или даже так: иных способов, кроме штатно предусмотренных в системе?

Croco ()
Ответ на: комментарий от Croco

Или вы не знаете о существовании иных способов получения доступа, нежели подбором пароля?

Ещё раз. Чем отличается пара логин/пароль у привилегированного и непривилегированного пользователя с точки зрения получения доступа?

AS ★★★★★ ()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

Чем отличается пара логин/пароль у привилегированного и непривилегированного пользователя с точки зрения получения доступа?

Ну зачем же так тупить?

Отвечу за Croco, пожалуй.

Пара логин/пароль ничем не отличается. Отличается лёгкость взлома аккаунта.

Получить доступ к аккаунту непривилегированного пользователя гораздо проще, потому, что под этим пользователем обычно запускается куча потенциально уязвимых программ (современные браузеры, как наиболее яркий пример). Запускать же эти программы от рута никто в здравом уме не будет, поэтому к аккаунту рута получить доступ значительно сложнее. Но сложнее лишь в том случае, если вышеупомянутый непривилегированный пользователь с браузером наперевес не имеет возможности повысить свои полномочия до рута.

Croco всё правильно говорит, повышение привилегий в принципе весьма опасная штука, всем специалистам по безопасности это хорошо известно. С другой стороны можно и руки после туалета не мыть, авось (не)пронесёт.

anonymous ()
Ответ на: комментарий от anonymous

Получить доступ к аккаунту непривилегированного пользователя гораздо проще, потому, что под этим пользователем обычно запускается куча потенциально уязвимых программ (современные браузеры, как наиболее яркий пример)

Кто тебе сказал такую чушь, что под пользователем, для которого права даны в sudo, запускается куча потенциально уязвимых программ?

Croco всё правильно говорит, повышение привилегий в принципе весьма опасная штука, всем специалистам по безопасности это хорошо известно.

Да, я вижу тут охрененное количество специалистов по bla-bla-blaзубрилок по безопасности. :-)

AS ★★★★★ ()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

Кто тебе сказал такую чушь, что под пользователем, для которого права даны в sudo, запускается куча потенциально уязвимых программ?

А ты проведи опрос на ЛОРе: «какие права в sudoers установлены у вашего основного пользователя?». Уверен, у подавляющего большинства там что-нибудь типа ALL=(ALL:ALL) ALL. И хорошо ещё, если не NOPASSWD.

anonymous ()
Ответ на: комментарий от anonymous

А ты проведи опрос на ЛОРе: «какие права в sudoers установлены у вашего основного пользователя?»

А при чём тут sudo тогда? Опять же, хост хосту рознь, есть хосты, где под обычным пользователем вообще ничего не запускают. Запускают либо под специальными, либо под root. Сервера называются. Почему бы там не иметь ALL=(ALL:ALL) ALL ? И даже логи могут там не смотреть потому, что remote syslog.

AS ★★★★★ ()
Ответ на: комментарий от AS

А при чём тут sudo тогда?

Не при чём, конечно же. Программа не виновата, что количество людей, знающих как её безопасно использовать, стремится к нулю. И что количество случаев, когда она реально нужна, весьма невелико.

Зато есть повсеместно в десктопном линуксе пропагандируемый подход: всё, что требует суперпользовательских прав, делать через sudo (запуская его, естественно, от основного пользователя). Будешь ли ты и тут спорить и утверждать, что так и надо?

anonymous ()
Ответ на: комментарий от anonymous

что требует суперпользовательских прав, делать через sudo (запуская его, естественно, от основного пользователя)

У каждого компьютера своё предназначение и свой необходимый уровень защиты. Везде с максимальным работать сложно.

Будешь ли ты и тут спорить и утверждать, что так и надо?

То есть, ты согласен со мной, что в RedHat не всё здорово?

AS ★★★★★ ()
Ответ на: комментарий от AS

У каждого компьютера своё предназначение и свой необходимый уровень защиты.

И пока пользователь не разберётся, что такое «уровень защиты» и какой именно уровень ему лично необходим, рекомендовать ему пользоваться sudo — чистой воды вредительство.

Будешь ли ты и тут спорить и утверждать, что так и надо?

То есть, ты согласен со мной, что в RedHat не всё здорово?

Таки, а почему ви отвечаете вопгосом на вопгос? ;)

Непонятно, как мой вопрос и sudo ты связываешь с RedHat. Тем не менее, я отвечу. Я вообще считаю, что с линуксом в целом сейчас не всё здорово. Уж по крайней мере с теми дистрибутивами, которые контролируют крупные компании. Да и в ядро они гадят порядочно.

anonymous ()
Ответ на: комментарий от anonymous

Непонятно, как мой вопрос и sudo ты связываешь с RedHat.

Ну потому, что пользователю достаточно оказаться в группе wheel, чтобы получить права root. Это прямо как sudo c NOPASSWD.

AS ★★★★★ ()
Ответ на: комментарий от AS

пользователю достаточно оказаться в группе wheel, чтобы получить права root.

Да? Не знал. Впрочем, на фоне всего остального говна, которое они делают, моё отношение к RedHat этот мелкий факт вряд ли как-то ухудшит.

anonymous ()
Ответ на: комментарий от Croco

Понижать можно, повышать нельзя. В противном случае теряется смысл существования непривилегированных аккаунтов

У тебя ущербная логика. Если ей следовать, то никаких «ssh'ем можно _только_ в него» быть не может, потому что, где гарантия, что то, откуда ты ssh-ем само уже не скомпрометировано? Кто это гарантирует? Ты? Со своей какой-то особенной дисциплиной? Чушь! Если так, то я тоже это буду гарантировать своей дисциплиной и sudo.

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

А если же нет, то где разница между твоей и моей дисциплиной? С чего ты решил, что твоя вдруг лучше?

anonymous ()
Ответ на: комментарий от anonymous

где разница между твоей и моей дисциплиной?

Сравнивать «мою» и «твою» дисциплину имело бы смысл, если бы я заявил, что ты вообще на своих серверах никогда не должен работать под root'ом, потому что не умеешь обеспечивать безопасность, а я вот умею, и поэтому ты должен платить мне бешеные бабки, а администрить твои сервера буду я.

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

Если же вернуться к моему исходному утверждению о недопустимости повышения полномочий в сеансе работы, то, естественно, здесь речь идёт _только_ о _моей_ «дисциплине». Точнее, речь идёт о _моих_ аккаунтах: root на сервере, простой юзер на том же сервере, root на рабочей станции, простой юзер, опять же, на той же станции. Здесь мне совершенно очевидно, что юзера на рабочей станции я могу при необходимости защитить намного лучше, чем юзера на сервере. В конце концов, на станции у меня может не быть ни одного слушающего порта, так что ломать её можно будеть разве что через стек TCP/IP в ядре (вроде там давно не было серьёзного ничего), да плюс она может быть за тремя NAT'ами (конечно, это не панацея, но всё-таки их все три придётся разломать, чтоб до моей станции добраться), да к тому же включена не всегда, а только во время работы (взломать станцию прямо у меня под руками всё же сложнее, чем взломать компьютер, предоставленный самому себе, пока я ночью дрыхну). На сервере ничего этого не получится, он и работать должен постоянно, и порты открытые на нём есть всегда (иначе какой это нафиг сервер), и за NAT'ом он быть не может.

Можно ли повышать полномочия из непривилегированного юзера на сервере в рута на том же сервере при условии, что юзера этого там охраняют столь же тщательно, как и рута? В принципе можно, только (а) так не бывает и (б) если этого всё-таки добиться, существование отдельного непривилегированного пользователя лишается смысла, поскольку его вообще-то как раз и заводят именно чтобы при работе с ним не нужно было придерживаться таких же строгих самоограничений, как при работе под root'ом.

Croco ()