Здравствуйте, Евгений Музыченко, Вы писали:
Pzz>>tar распаковывает с теми правами, с которыми запаковано.
ЕМ>Если так, то это явная глупость.
Pzz>>А что он должен делать?
ЕМ>Сбрасывать флаг E при распаковке, если явно не указано обратное (соответствующим ключом командной строки).
С чего бы это? Зачем было бы нужно такое умолчание?
Здравствуйте, Евгений Музыченко, Вы писали:
N>>С чего бы это? Зачем было бы нужно такое умолчание?
ЕМ>С того же и затем же, что по умолчанию файлы создаются без флага E, он всегда устанавливается явно.
Во-первых, что такое флаг E? Ты о какой ОС вообще говоришь? Если про Unix семейство (думаю, раз пошёл разговор в подветке), то там есть 3 флага: S_IXUSR,S_IXGRP, S_IXOTH (user, group, other соответственно). В стандартном выводе ls в формате вывода -rwxrwxrwx это все x соответственно.
Во-вторых, никакого такого умолчания нет, тебя обманули. На каждое создание файла 3-й аргумент open() и аналогичные аргументы всяких более современных openat() содержат полную маску, которая затем сбрасывается по текущей umask процесса (которая обычно, средствами init-процесса, установлена в 0o22, то есть S_IWGRP|S_IWOTH (заметь, это не флаги исполнения!) или почему-то в современных редхатоидах и дебианоидах в 002 (я исправляю у себя).
Ты можешь вызвать open(path, O_CREAT|..., S_IRUSR|S_IWUSR|S_IXUSR), например, и он будет исполняемым с ходу, но только для владельца. Часто такие маски пишут идиомами, и, например, 0644 — стандартные права для неисполняемого, 0755 — для исполняемого.
Так что пересмотри свои знания и не пори чушь.
(PS: На самом деле, в некоторых ситуациях, как минимум, не вредно создавать вначале файл с минимальными правами и только после заливки всего содержимого ставить полный комплект. Так вот — сюрприз — обычные tar типа GNU реализации именно так и делают! Так что и тут проблемы нет.)
Здравствуйте, netch80, Вы писали:
N>что такое флаг E?
"x". Я не юниксоид, мне простительно.
N>Ты о какой ОС вообще говоришь? Если про Unix семейство
Ага.
N>Во-вторых, никакого такого умолчания нет, тебя обманули. На каждое создание файла 3-й аргумент open() и аналогичные аргументы всяких более современных openat() содержат полную маску, которая затем сбрасывается по текущей umask процесса
Если в open() явно не указаны S_IXxxx, то у файла "они сами" собой (за счет попутной коррекции) не возникнут, а вот другие флаги — могут. Это и есть "умолчание".
N>Ты можешь вызвать open(path, O_CREAT|..., S_IRUSR|S_IWUSR|S_IXUSR), например, и он будет исполняемым с ходу
За это отвечает тот, кто такое использует.
Если действительно заботиться о безопасности, то нет никаких оснований позволять архиватору восстанавливать файлы с правами выполнения без явного на это указания. Ситуация, в которой никак не ограничивается создание исполняемых файлов "втихую", но при этом необходимость префикса "./" подается, как "мера безопасности", выглядит весьма уродливо.
Здравствуйте, Евгений Музыченко, Вы писали:
N>>что такое флаг E? ЕМ>"x". Я не юниксоид, мне простительно.
Ладно. Но помни, что их три. (Пять, если считать с suid и sgid.)
N>>Во-вторых, никакого такого умолчания нет, тебя обманули. На каждое создание файла 3-й аргумент open() и аналогичные аргументы всяких более современных openat() содержат полную маску, которая затем сбрасывается по текущей umask процесса
ЕМ>Если в open() явно не указаны S_IXxxx, то у файла "они сами" собой (за счет попутной коррекции) не возникнут, а вот другие флаги — могут. Это и есть "умолчание".
Неправда. "Другие" не возникнут.
Если ты поставишь начальную маску прав 0, будет 0 (и записать в такой ничего не сможешь, но открыть сможешь).
Если ты не поставить флаги права записи, не будет права записи. Ядро не проявит никакой инициативы добавить другие флаги.
Так что нет тут никакого "умолчания" в ядре.
Есть только традиции открывать, да, по умолчанию с определёнными флагами, но это уже не уровень ядра.
N>>Ты можешь вызвать open(path, O_CREAT|..., S_IRUSR|S_IWUSR|S_IXUSR), например, и он будет исполняемым с ходу ЕМ>За это отвечает тот, кто такое использует.
Да.
ЕМ>Если действительно заботиться о безопасности, то нет никаких оснований позволять архиватору восстанавливать файлы с правами выполнения без явного на это указания.
Продолжаю недоумевать причинам такого утверждения. Это только из-за форсирования префикса `./`?
EM> Ситуация, в которой никак не ограничивается создание исполняемых файлов "втихую", но при этом необходимость префикса "./" подается, как "мера безопасности", выглядит весьма уродливо.
Тебе привели случай с разархивацией только как пример. Источников же исполняемого файла с совпадающим названием может быть сколько угодно, архиватором они не ограничиваются.
Насколько я помню, первые случаи были связаны как раз с ручной подкладкой юзерами троянов для человека-рута с названиями типа ls, du. Потом проблема была осознана и для административных скриптов.
Такое впечатление, что ты сейчас упорствуешь только ради того, чтобы не сдаваться, где это уже не имеет смысла.
Здравствуйте, Pzz, Вы писали:
Pzz> Ну действительно, не дело это, когда выбор запускаемой программы зависит от текущей директории.
честно, не понял формулировки
Чтобы выбор запускаемой программы не зависел от текущей директории, путь должен быть абсолютным, а не путём относительно текущей директории.
./my.exe — это же путь относительно текущей директории.
Здравствуйте, CRT, Вы писали:
Pzz>> Ну действительно, не дело это, когда выбор запускаемой программы зависит от текущей директории.
CRT>честно, не понял формулировки
Венда/DOS сначала ищут в текущей директории, а потом уже в пути...
Здравствуйте, Pzz, Вы писали:
Pzz>Венда/DOS сначала ищут в текущей директории,
я это знаю.
но когда ты в терминале пишешь ./my.exe , то что будет запущено, зависит таки от текущей директории, а ты говоришь "не дело это, когда выбор запускаемой программы зависит от текущей директории".
В одной директории один my.exe, в другой — другой. И в зависимости в какой ты директории стоишь, твоя команда ./my.exe запустит разные my.exe
Pzz>а потом уже в пути...
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Можно перечислить хотя бы первые три из "многочисленных" проблем, а также описать варианты случайного и намеренного "подсовывания" программы?
Ну вот скачал ты архив, распаковал, заходишь в каталог и пишешь `dir`, чтобы посмотреть список файлов. А там раз и `dir.exe` запускается из текущего каталога. Нежданчик. В винде может быть это не так выражено, там консоль такая убогая, что туда заходят только по большой нужде, а в юниксах консоль удобная и многие ей пользуются вместо файлового менеджера.
Здравствуйте, netch80, Вы писали:
N>Такое впечатление, что ты сейчас упорствуешь только ради того, чтобы не сдаваться, где это уже не имеет смысла.
Дык ничего нового
Спасибо за информацию, кстати, в том числе историческую. Невоинственным невеждам сплошная польза.
Можешь посоветовать что-то из литературы по линуксу в виде книги, где подобные темы освещаются? (совсем базовым уровнем типа 0644/0755 я владею, а вот что там с umask — уже нет. Понятное дело, почитаю ман, но хотелось бы чего-то системного). Недавно столкнулся по работе с несозданием кор-дампа процессом, у которого setcap netadmin выставлен. Нагуглил в итоге, но ощущение противное, когда не понимашь систему концептуально, а скакание по манам и гуглам не даёт полноты картины.
Здравствуйте, CRT, Вы писали:
CRT>но когда ты в терминале пишешь ./my.exe , то что будет запущено, зависит таки от текущей директории, а ты говоришь "не дело это, когда выбор запускаемой программы зависит от текущей директории".
А вот когда ты просто пишешь my.exe, то в венде выбор зависит, а в UNIX — нет.
Pzz>>а потом уже в пути...
CRT>не в пути, а в путях указанных в переменной PATH
Здравствуйте, vsb, Вы писали:
vsb>Ну вот скачал ты архив, распаковал, заходишь в каталог и пишешь `dir`, чтобы посмотреть список файлов. А там раз и `dir.exe` запускается из текущего каталога.
Как раз с dir этот номер не пройдет. Dir — внутренняя команда. Вот с внешними да, может. Видимо, не напрасно во многих конторах, занимающихся администрированием, не разрешают использовать консольные команды. Разрешают делать все только через GUI.
Здравствуйте, serg_joker, Вы писали:
_>Спасибо за информацию, кстати, в том числе историческую. Невоинственным невеждам сплошная польза. _>Можешь посоветовать что-то из литературы по линуксу в виде книги, где подобные темы освещаются? (совсем базовым уровнем типа 0644/0755 я владею, а вот что там с umask — уже нет. Понятное дело, почитаю ман, но хотелось бы чего-то системного). Недавно столкнулся по работе с несозданием кор-дампа процессом, у которого setcap netadmin выставлен. Нагуглил в итоге, но ощущение противное, когда не понимашь систему концептуально, а скакание по манам и гуглам не даёт полноты картины.
Я считай после ~2000 именно на базовую литературу подобного рода не смотрел, только уже на сильно более специализированное. А из тех времён было несколько книг вполне симпатичных:
1. Робачевский "Операционная система Unix" — тут больше ориентация на программирование и базовое API, но очень системно.
2. "Секреты Unix" — несмотря на название это просто систематическое обширное введение как для пользователя. Там все эти особенности поданы уже с точки зрения что они значат и как используются — а это существенно.
3. Книги от Richard W. Stevens по общему ("Advanced programming in Unix environment") и сетевому программированию, были и в переводе.
4. Eric Raymond — "TAoUP" — это уже в основном не что вызывать а зачем его вызывать
В принципе этого хватало как для отличного старта. Эти три не учитывают множество новшеств типа контейнеров (разве что их предков типа chroot/jail), at-семейство функций, продвинутый AIO, очень мало про многонитевость. Но база есть и хорошо рассмотрена.
Про встроенную документацию: "маны" это уже справочник, их читать можно только уже зная, куда идти. Дальше нужно делать, например, как всегда у Microsoft — на любую подсистему три секции: обзор, howto для типичных случаев, и справочник (аналогичный манам). Для обзора годятся, например, Developers Handbook, но это для FreeBSD, многое для Linux уже совсем другое. С ходу аналогичных примеров для Linux не нашёл — хм, их сейчас нет или просто не вспомнилось? Можно, конечно, начать с info libc, там тоже иерархический метод, но там не будет множества тонкостей.
Сейчас перечитал это — хм, выглядит странным, что нет какого-то ни онлайн ни бумажного новшества — или давно не обновлялись, или я просто не замечаю. Кто бы прокомментировал.
Здравствуйте, vsb, Вы писали:
vsb>Ну вот скачал ты архив, распаковал, заходишь в каталог и пишешь `dir`, чтобы посмотреть список файлов. А там раз и `dir.exe` запускается из текущего каталога. Нежданчик. В винде может быть это не так выражено, там консоль такая убогая, что туда заходят только по большой нужде, а в юниксах консоль удобная и многие ей пользуются вместо файлового менеджера.
Файловый менеджер обычно использует тот же PATH, если команда набирается явно, а не в варианте ткнуть Enter на исполняемом файле.
vsb>Ну а если хочется — добавить `.` в PATH недолго.
Здравствуйте, Privalov, Вы писали:
vsb>>Ну вот скачал ты архив, распаковал, заходишь в каталог и пишешь `dir`, чтобы посмотреть список файлов. А там раз и `dir.exe` запускается из текущего каталога.
P>Как раз с dir этот номер не пройдет. Dir — внутренняя команда. Вот с внешними да, может. Видимо, не напрасно во многих конторах, занимающихся администрированием, не разрешают использовать консольные команды. Разрешают делать все только через GUI.
При этом в половине случаев окажется, что GUI внутри себя зовёт консольную команду (для юникса — через любой шелл, для винды — через PowerShell или аналог).
Не знаю, что это за "многие конторы", но если обоснование такого запрета именно такое, то это совершенно клиническая глупость.
Больше похоже, что там рулят древние мудаки, для которых даже cmd.exe это новомод.
Здравствуйте, netch80, Вы писали:
N>помни, что их три.
Так я помню.
N>Продолжаю недоумевать причинам такого утверждения. Это только из-за форсирования префикса `./`?
Из-за деклараций о том, что он снижает риски, на фоне того, что в других местах риски снижать никто не собирался и не собирается.
N>Тебе привели случай с разархивацией только как пример. Источников же исполняемого файла с совпадающим названием может быть сколько угодно, архиватором они не ограничиваются.
Так я в курсе. По-хорошему, все такие источники должны требовать явное, прозрачное указание на возможность наделения файла правом исполнения. Если, конечно, нас действительно интересует безопасность.
N>Насколько я помню, первые случаи были связаны как раз с ручной подкладкой юзерами троянов для человека-рута с названиями типа ls, du.
Вот тоже странно, почему такие уязвимости привели к введению обязательного "./", а не к устранению возможности для обычного юзера что-то подсунуть администратору.
N>Такое впечатление, что ты сейчас упорствуешь только ради того, чтобы не сдаваться, где это уже не имеет смысла.
Я всегда упорствовал и буду упорствовать в том, что безопасность должна быть комплексной, а не костыльной.
