Comments 305
Ровно как и нотаризация для Mac OS
А чем ТАК уж проблематична в этом плане именно нотаризация?
Требование Developer account — ну так если вы разрабатываете под macOS у вас он видимо и так есть (а если нет — не такая уж проблема получить)
То, что процедура выпуска релиза начинает зависить от отсылки файлов Apple'у? Ну так а был хоть раз случай когда на нотаризацию прилетал необоснованный отказ?
Аналог того что в статье — у Apple это гейткипер — про который в принципе все кто ставят софт — знают и как отключать/обходить в конкретном случае — знают. При этом для тех же Homebrew пакетов это вообще не проблема.
Требование Developer account — ну так если вы разрабатываете под macOS у вас он видимо и так есть (а если нет — не такая уж проблема получить)
То, что процедура выпуска релиза начинает зависить от отсылки файлов Apple'у? Ну так а был хоть раз случай когда на нотаризацию прилетал необоснованный отказ?
Аналог того что в статье — у Apple это гейткипер — про который в принципе все кто ставят софт — знают и как отключать/обходить в конкретном случае — знают. При этом для тех же Homebrew пакетов это вообще не проблема.
достаточно распостранять инсталляторы в архивах и никакой смартскрин не страшен ;)
Боюсь что нет. Как образчик — «драйверы торгового оборудования» от атол версий 8.16.4...8.16.6 — там была куча веселостей с [не]установкой подписанного драйвера usb-serial и запозданием появления репутации на пару-тройку версий. В свое время весело читался форум их поддержки (все подписано, файлы в мс отправлены).
Ага. Глядя на них мы тоже решили не заморачиваться с подписью. Что с ней что без неё были проблемы. А теперь из статьи понятно почему. Душат нашего брата.
я уже не одну тысячу инсталляторов раздал в архивах — и никаких проблем со смартскрином
«с моей стороны пакеты ушли»)
А по факту — тот самый пример на слуху про атол — там юзеров не меньше. Притом проблемы у людей возникали просто стохастически. Типа партия компьютеров-клонов (из одной поставки с OEM виндой и с идентичным софтом) из них на 9 драйвер ставится, на 10 — нет…
А по факту — тот самый пример на слуху про атол — там юзеров не меньше. Притом проблемы у людей возникали просто стохастически. Типа партия компьютеров-клонов (из одной поставки с OEM виндой и с идентичным софтом) из них на 9 драйвер ставится, на 10 — нет…
Windows при загрузке zip выставляет файлу атрибут что он «с интернета» и далее если в проводнике в него войти и запустить exe — применяет к нему ту же политику что и для напрямую скаченных exe. Можно зайти в свойства файла и поставить галочку «разблокировать», но обычно это никто не делает.
Конечно если вы zip каким то WinRar распаковываете а не встроенным способом, то тогда этот атрибут при распаковке потеряется и сообщения не будет.
И кстати EV сертификаты уже не помогают. Помогает только тысяча-две скаченных и запущенных файлов другими пользователями чтобы у майкрософта набралась статистика на этот сертификат.
Конечно если вы zip каким то WinRar распаковываете а не встроенным способом, то тогда этот атрибут при распаковке потеряется и сообщения не будет.
И кстати EV сертификаты уже не помогают. Помогает только тысяча-две скаченных и запущенных файлов другими пользователями чтобы у майкрософта набралась статистика на этот сертификат.
и при распаковке и запуске инсталлятора — привет SmartScreen
Это почему?
При скачивании браузер добавляет к файлу NTFS-stream с именем Zone.Identifier, куда помещает ссылку, откуда скачан файл. SmartScreen ругается именно на файлы с этим NTFS-потоком.
Если файл распакован из 7z-архива (к примеру), архиватор этот поток не дописывает к файлу.
При скачивании браузер добавляет к файлу NTFS-stream с именем Zone.Identifier, куда помещает ссылку, откуда скачан файл. SmartScreen ругается именно на файлы с этим NTFS-потоком.
Если файл распакован из 7z-архива (к примеру), архиватор этот поток не дописывает к файлу.
Вы путаете.
Это не имеет никакого отношения к сертификату. Скрытый поток — это локальная штука в рамках одной конкретной машины, а смарт-скрин работает с облачным сервисом.
Пока вы не снимете галочку в свойствах файла операционка не даст вам обратиться к скачанному из интернета исполняемому файлу, каким бы сертификатом он не был подписан.
Это не имеет никакого отношения к сертификату. Скрытый поток — это локальная штука в рамках одной конкретной машины, а смарт-скрин работает с облачным сервисом.
Пока вы не снимете галочку в свойствах файла операционка не даст вам обратиться к скачанному из интернета исполняемому файлу, каким бы сертификатом он не был подписан.
Это не совсем так, если репутация высокая, файл запустится сразу же, не смотря на NTFS-поток (пример). Насколько я помню, анализируется не только сертификат, но и пути распространения.
если у файла нет Zone.Identifier то смартскрин не обращает на него никакого внимания
Пока вы не снимете галочку в свойствах файла операционка не даст вам обратиться к скачанному из интернета исполняемому файлу, каким бы сертификатом он не был подписанИменно что к скачанному, а реализуется этот механизм через добавление NTFS-потока браузерами. А если файл распакован из архива (или появился на машине пользователя например компиляцией из Visual Studio), SmartScreen не срабатывает.
Предполагаю такую логику: Если пользователь смог разархивировать, то это уже продвинутый пользователь, ему SmartScreen не нужен.
По классике :)
Я тоже хакер, я сменил обои
Ах вот откуда все эти тысячи программ, которые запросто могли бы работать как экзешник, но зачем-то требуют root-next-next-finish :(
это он еще непробовал драйвер под десяточку написать/подписать, вот где веселье так веселье
Там хотя бы фиксированный алгоритм, никаких оценок и репутаций. EV-сертификат, Attestation-подпись — всё, драйвер загрузился.
Обычному разработчику-физлицу, конечно, это недоступно, да. Ну так это не вчера началось, а ещё в Висте, когда в 64-битные винды запретили грузить драйверы, не подписанные покупным сертификатом. Помнится, и обычный-то сертификат для подписи драйверов физлицу невозможно было купить (а может, и до сих пор невозможно).
Обычному разработчику-физлицу, конечно, это недоступно, да. Ну так это не вчера началось, а ещё в Висте, когда в 64-битные винды запретили грузить драйверы, не подписанные покупным сертификатом. Помнится, и обычный-то сертификат для подписи драйверов физлицу невозможно было купить (а может, и до сих пор невозможно).
Кстати, я тоже читал, что конкретно для Win10 драйвер ядра нужно подписывать только EV-сертификатом, однако подписал это и драйвер прекрасно работает везде, включая Win10 x64, хотя сертификат самый обычный (был куплен, когда DigiCert ещё не свернули программу для Sysdevs).
Там на самом деле есть несколько условий, при которых обычная (не-MS) подпись принимается системой. Все наизусть не помню, но ключевые:
1. Если драйвер был подписан до введения десяточных ограничений (и это удостоверено таймштампом).
2. Если драйвер был подписан после ограничений, но сертификатом, выписанным до введения этих ограничений (2015-й что ли год).
3. Если винда загружена без Secure Boot.
4. Если винда была установлена не начисто, а как апгрейд с 7/8/8.1.
Во всех этих случаях даже EV не требуется, достаточно стандартного code signing с кросс-сертификатом. В остальных же случаях нужна Microsoft-подпись, которую можно получить, только если компания обладает EV-сертификатом.
1. Если драйвер был подписан до введения десяточных ограничений (и это удостоверено таймштампом).
2. Если драйвер был подписан после ограничений, но сертификатом, выписанным до введения этих ограничений (2015-й что ли год).
3. Если винда загружена без Secure Boot.
4. Если винда была установлена не начисто, а как апгрейд с 7/8/8.1.
Во всех этих случаях даже EV не требуется, достаточно стандартного code signing с кросс-сертификатом. В остальных же случаях нужна Microsoft-подпись, которую можно получить, только если компания обладает EV-сертификатом.
В том-то и дело, что всё мимо. Конкретно этот драйвер работает только без Secure Boot, это указывал автор, но я пробовал другие и они работают с Secure Boot. Единственное отличие, что заметил — это диалог подтверждения доверия при установке из inf и необходимость использования ключа /ForceUnsigned при интеграции, но оба эти пункта легко автоматизируются. Четвёртый пункт интересный, скорее всего несложно добавить в систему соответствующую отметку.
А вообще механизм проверки сертификатов несколько глючный, например на Win7 без KB3125574 диалог подтверждения издателя будет возникать всегда, а драйвера без валидной подписи интегрируются успешно без ключа /ForceUnsigned.
А вообще механизм проверки сертификатов несколько глючный, например на Win7 без KB3125574 диалог подтверждения издателя будет возникать всегда, а драйвера без валидной подписи интегрируются успешно без ключа /ForceUnsigned.
Было бы интересно разобраться, что именно заставляет десятку принять эту подпись. Тем более, что она SHA-1, а вроде бы, они энное время назад перешли исключительно на SHA-256. А может, именно в этом и дело; скажем, SHA-1 считается устаревшей и для её обработки включаются старые механизмы проверки, не учитывающие новые требования…
Да, достаточно обычного сертификата. С EV просто не будет возникать окно с подтверждением издателя. Несколько сложнее, см. коммент выше.
Кроме того, если менялся только .inf, а .sys уже подписанные, то можно вообще воспользоваться libwdi для автоподписания .cat
https://github.com/pbatard/libwdi
Attestation-подпись получить — весьма затратный и не тривиальный процесс
Все эти цифровые подписи EV/не EV — такое глобальное, как бы так поцензурнее выразиться, разводилово. Но слово, другое подходит больше. SmartScreen это еще пол беды, другие антивирусы в принципе, зачастую, игнорируют наличие цифровой подписи. Всю историю нашего продукта мы воюем с антивирусами. Многостраничные, практически ежегодные, переписки идут практически со всеми известными вендорами.
Если обобщить — антивирусы плевать хотели на ЦП, это довольно ничтожный фактор, который иногда играет даже в минус, в том случае, если в базе есть, к примеру, предыдущая версия продукта с такой же ЦП, но на которую не оформлен / не рассмотрен рапорт о false positive.
При этом, злоумышленники довольно легко обходят эти самые антивирусы, заворачивая свои «дропперы» во вполне легальные протекторы софта, и очень часто это срабатывает! В то время как мы, разработчики легального софта, даже подумать не можем о применении протектора, тогда вообще никому ничего не докажешь при рассмотрении false positive кейса.
ЦП — это хорошо. Это единственный правильный путь, но все должно быть организовано как у Эппла, к примеру. Деньги платишь, но знаешь за что их платишь. Для Windows получается, что регулярно выкладывается приличная сумма денег за EV, а толку от этого ноль.
Систему сертификации нужно полностью менять и реформировать. Сейчас она не обеспечивает ни защиты вендоров от ложных срабатываний, ни защиты пользователей от вредоносного софта.
С третьей стороны, внедрение грамотной системы сертификации фактически уничтожит отрасль антивирусов.
Если обобщить — антивирусы плевать хотели на ЦП, это довольно ничтожный фактор, который иногда играет даже в минус, в том случае, если в базе есть, к примеру, предыдущая версия продукта с такой же ЦП, но на которую не оформлен / не рассмотрен рапорт о false positive.
При этом, злоумышленники довольно легко обходят эти самые антивирусы, заворачивая свои «дропперы» во вполне легальные протекторы софта, и очень часто это срабатывает! В то время как мы, разработчики легального софта, даже подумать не можем о применении протектора, тогда вообще никому ничего не докажешь при рассмотрении false positive кейса.
ЦП — это хорошо. Это единственный правильный путь, но все должно быть организовано как у Эппла, к примеру. Деньги платишь, но знаешь за что их платишь. Для Windows получается, что регулярно выкладывается приличная сумма денег за EV, а толку от этого ноль.
Систему сертификации нужно полностью менять и реформировать. Сейчас она не обеспечивает ни защиты вендоров от ложных срабатываний, ни защиты пользователей от вредоносного софта.
С третьей стороны, внедрение грамотной системы сертификации фактически уничтожит отрасль антивирусов.
Разводилово — это мягко сказано. Фактически, приходится тратить время на высылку кучи документов, деньги на адвокатов для подтверждения бумаг компании, деньги на сам EV Code Sign сертификат. А профит — просто не срабатывает смартскрин. Причем как и у автора в статье, сначала купили простой Code Sign сертификат, а потом стало понятно, что сэкономить не получится, т.к. половина пользователей, увидев сообщение смартскрина, сразу закрывают установку. Кстати говоря, на win 10 смартскрин еще не самое пугающее сообщение выдает. На том же Win Server 2019 табличка такая, что даже читать не хочется, сразу хочется закрыть. Молчу уже, что в условиях пандемии, у нас ушел месяц, что бы получить его.
Всё так и есть, антивирусов развелось как собак, а сами они и центры сертификации плевать хотели на разработчиков и их пользователей, главное состричь побольше. Неплохой вариант был бы таким, когда разработчик за небольшую сумму сертификации получает иммунитет сразу для всех антивирусов (можно на уровне системы запрещать работу несертифицированных антивирусов), а программа с валидной подписью получала бы статус вредоносной только при экспертной проверке, чтобы исключить ложное срабатывание. Но так-то да, такая система сделает ненужными антивирусы, а они там гребут будь здоров и будут сопротивляться.
программа с валидной подписью получала бы статус вредоносной только при экспертной проверке
так оно так и есть
Увы нет, проверяет автоматика.
антивирусы плевать хотели на ЦП
Если бы. К сожалению сейчас приложение без легитимной подписи и неизвестное антивирусу рассматривается как подозрительное
Так это они вам, мягенько, намекают — windows store.
Вроде бы для СНГ аккаунт разработчика стоит не дорого.
Вроде бы для СНГ аккаунт разработчика стоит не дорого.
я, как пользователь, больше заинтересован в защите своих данных, чем ваших (понимаю, что перевод, обращаюсь как бы к автору) возможностей распространять свое ПО. Если ваше ПО столь редко распространено, то пользуются им, скорее всего, гики или ИТ-подкованные спецы, к-рые корректно обработают это сообщение. А для неспециалистов, как мне кажется, лучше уж отказаться от нес-ких пока еще нераспознанных «бриллиантов», чем один раз влететь на шифровальщика. При этом я сомневаюсь, что ваше ПО столь уникально и для него нет well-known замены.
То есть все нужное ПО уже написано, а если вдруг и не написано, то пусть его пишет кто-то из известных игроков на рынке, все верно?
то есть меня, как потребителя, ваши проблемы, как писателя ПО, не волнуют. И, если вендор ПО делает сложнее вам, но безопаснее мне, честь ему и хвала. Это, к тому же, больше риски этого самого вендора. Понятно, что этому вендору проще, т.к. он крупный и широко распространенный. Но c'est la vie.
Вам как пользователю наоборот невыгодно, что не можете легко запустить новую программу только потому, что на уровне системы этот механизм плохо продуман. В статье идёт речь о том, что фильтр SmartScreen работает с презумпцией виновности, тогда как с людьми наоборот работает презумпция невиновности, что более логично и правильно.
И вы пришли прочитать пост про наши проблемы, чтобы написать комментарий как эти проблемы вас не волнуют? Ну эээ… Держите нас в курсе.
Это не просто пост про ваши проблемы (которые не только ваши — все мы выполняем разные роли в разное время), а формирование мнения. К сожалению — без попыток взглянуть с другой стороны (вендора и пользователя). Такая позиция, скорее всего, будет ущербной (не сбалансированной). Требуется мнение и другой стороны. Не в формате "ну вам же, очевидно, это невыгодно ".
Софт, обычно, не существует в вакууме. С чего вдруг программа, у автора которой нет лишних денег на подписи, чем-то лучше или хуже программы, у автора которой они есть? Текущая ситуация плоха и для нишевых независимых разработчиков, и для их пользователей, вот эти стороны тут играют роль. Вы, вероятно, не представитель ни одной из них.
Тут, как мне кажется, много причин. И одна из них в том, что для приобретения сертификата разработчика нужно оставить некий след. Более того, положительный фидбек от многих приложений, подписанных одним сертификатом, явно отличается от целей мошенников, которые, даже получив сертификат, не будут им подписывать все свои наработки. То есть, никто не говорит, что неподписанное ПО хуже, просто его конкурент явно предпринял больше шагов для подтверждения своей добросовестности.
Это, BTW, примерно, как с кредитной историей: чтобы получить лучшие условия по кредиту, вам неплохо бы иметь хорошую кредитную историю. Хотя она может быть у вас только после получения кредита.
В общем, доверие зарабатывают, а не получают сразу.
Я какое-то время подписывал программу GoodbyeDPI сертификатом, который покупался для подписи вирусов у случайного барыги, который и сам наверняка подписывал им вирусы еще до продажи.
Сертификат покупался у барыги, потому что это проще и быстрее: официальный сертификат может быть только на ИП публично (в сертификате будет указано ФИО), а при покупке на фирму, фирма должна быть публично представлена в интернете, содержаться в каких-то каталогах компаний, у неё должен быть указан рабочий телефон, продавцы сертификатов звонят, общаются с вами, требуют кучу документов. В общем, это нетривиальная процедура (сертификат для подписи вирусов до этого как-то раз покупался официально).
Волновало ли меня, что я использую вирусный сертификат для подписи легитимной программы? Нисколько.
Волновало ли это несколько десятков тысяч пользователей программы из разных стран? Нет, никто не спрашивал, что за Falconix Limited из Лондона делает в строке «издатель», все просто прокликивают эту ерунду.
Я точно не буду покупать X.509-сертификат для подписи своего ПО, потому что они фактически не работают так, как когда-то задумывалось, из-за чего не дают никаких гарантий. Разработчики настоящих троянов и ядерных руткитов используют уже подписанные действующими EV-сертификатами уязвимые драйверы. Сертификаты отзывают редко (зависит от размера компании), а если и отзывают, то эта процедура растягивается на месяцы. Только в последнем обновлении Microsoft начала блокировать автоматическую загрузку известных уязвимых драйверов в Windows.
Я подчеркну: не отзывать сертификаты, а вести свою собственную базу уязвимых драйверов, и блокировать их загрузку по умолчанию, до изменения настроек пользователем!
twitter.com/dwizzzleMSFT/status/1267507875619848198
P.S. Удивлён, что в статье описывается покупка сертификата на физ. лицо. Либо правила продажи изменились, либо на физ. лицо нельзя было продавать сертификаты россиянам: несколько компаний требовали либо ИП, либо фирму.
Сертификат покупался у барыги, потому что это проще и быстрее: официальный сертификат может быть только на ИП публично (в сертификате будет указано ФИО), а при покупке на фирму, фирма должна быть публично представлена в интернете, содержаться в каких-то каталогах компаний, у неё должен быть указан рабочий телефон, продавцы сертификатов звонят, общаются с вами, требуют кучу документов. В общем, это нетривиальная процедура (сертификат для подписи вирусов до этого как-то раз покупался официально).
Волновало ли меня, что я использую вирусный сертификат для подписи легитимной программы? Нисколько.
Волновало ли это несколько десятков тысяч пользователей программы из разных стран? Нет, никто не спрашивал, что за Falconix Limited из Лондона делает в строке «издатель», все просто прокликивают эту ерунду.
Я точно не буду покупать X.509-сертификат для подписи своего ПО, потому что они фактически не работают так, как когда-то задумывалось, из-за чего не дают никаких гарантий. Разработчики настоящих троянов и ядерных руткитов используют уже подписанные действующими EV-сертификатами уязвимые драйверы. Сертификаты отзывают редко (зависит от размера компании), а если и отзывают, то эта процедура растягивается на месяцы. Только в последнем обновлении Microsoft начала блокировать автоматическую загрузку известных уязвимых драйверов в Windows.
Я подчеркну: не отзывать сертификаты, а вести свою собственную базу уязвимых драйверов, и блокировать их загрузку по умолчанию, до изменения настроек пользователем!
twitter.com/dwizzzleMSFT/status/1267507875619848198
P.S. Удивлён, что в статье описывается покупка сертификата на физ. лицо. Либо правила продажи изменились, либо на физ. лицо нельзя было продавать сертификаты россиянам: несколько компаний требовали либо ИП, либо фирму.
Если "не EV", то некоторые компании продают физическим лицам, например Certum (в том числе для подписи OpenSource проектов за 28* евро/год)
Там слишком заморочено, для начала нужно купить USB-токен, а это уже 70 евро и не дешевле того же Comodo.
Являясь обладателем этого токена (на самом деле смарт-карты, и €45 за карту с ридером и €64 за доставку из Польши в Беларусь(!!!) ), могу сказать, что купить его было самым легким этапом получения сертификата.
Причем ещё два года назад можно было при помощи F12 в Internet Explorer воспользоваться стандартным криптопровайдером, сохранить всё что нужно в хранилище ОС, и вытащить через Mimikatz. Сейчас это провернуть не получилось.
не дешевле того же Comodo
На самом деле не дешевле.
Sectigo (бывший COMODO CA) не продаёт физлицам (мой случай), а для индивидуальных предпринимателей требует сложнодобываемые в СНГ вещи.
https://1drv.ms/w/s!AjPn0a7fFYvxgrxVr6zHy_eNrNp5jQ?e=c4Yfzu
Если сертификат отзовут, на Win10 из проводника программа вообще не запустится, а связываться с ком. строкой не каждый пользователь захочет.
Вы просто забываете, что цепочка рассуждений на этом не обрывается, а продолжается примерно таким образом: энтузиасты и мелкий бизнес не могут полноценно распространять свои программы, крупный бизнес остаётся без конкурентов и начинает впаривать глючный и тормозной шлак по задранной цене, всё равно пользователи схавают, деваться им некуда. Вывод: пользователи проиграют тоже. Ну а вендор, да, он в шоколаде, тут спорить сложно.
P.S. Пока писал, выше то же самое запостили.
P.S. Пока писал, выше то же самое запостили.
Ну блин, у вас так все просто: зайки кушают морковку, волки кушают заек. Сажайте меньше морковки, чтобы было меньше злых волков.
нет, мелкий уже бизнес сможет заплатить 100-1000 баксов, чтобы таки продавать свое ПО.
А если их софт не стоит для них того, чтобы $1000 выложить, то их пользователям придётся нажать лишнюю кнопочку. Потому, что другим пользователям это позволит не запустить какого-нибудь вируса или шифровальщика.
Обычно «вирусы и шифровальщики» используют уязвимости вполне легитимных и правильно подписанных программ. Ведь гораздо проще заставить пользователя запустить уже известное ему популярное ПО, чем какой-то непонятный exe.
А если разработчик распространяет ПО бесплатно, почему он всегда должен быть недоверенным или вообще платить за сертификацию? ПО должно быть дружелюбным для пользователя независимо от цены.
Если меназим защиты слишком часто дает false positive — пользователи првыкают к тому, что этот механизм не работает. И начинают его игнорировать.
Много крутого софта пишется по фану энтузиатсами. У которых есть желание вложить свои силы в разработку и раздать результат бесплатно, но нет желания платить живые бабки кому-то, чтобы раздавать результат бесплатно.
Много крутого софта пишется по фану энтузиатсами. У которых есть желание вложить свои силы в разработку и раздать результат бесплатно, но нет желания платить живые бабки кому-то, чтобы раздавать результат бесплатно.
1. если я скачаю Google Chrome, а при установке он мне выдаст недоверенный сертификат — это бинго, сработало.
2. если я скачаю некое ПО, а его разработчик не озаботился валидным сертификатом разработчика — это тоже звоночек. Как веса в антиспаме — сам по себе не повод отказаться, но при прочих равных предпочту подписанный софт.
2. если я скачаю некое ПО, а его разработчик не озаботился валидным сертификатом разработчика — это тоже звоночек. Как веса в антиспаме — сам по себе не повод отказаться, но при прочих равных предпочту подписанный софт.
Ну если бы оно работало так как вы говорите то это было бы отлично.
Вот только работает не так. О чем и говорится в статье.
Собственно смотрите пример с паленым скайпом ниже:
habr.com/ru/post/505194/#comment_21699280
Вот только работает не так. О чем и говорится в статье.
Собственно смотрите пример с паленым скайпом ниже:
habr.com/ru/post/505194/#comment_21699280
Вот я написал себе на коленке, пару строк кода.
они работают, работают шустрей классических програм. Кушают мало.
да, падают, да интерфейс страшный. Ну и что?
потом её увидел приятель, взял, потом ещё кто-то попросил. Потом я программу с кратким руководством выложил в инет.
хочешь сертификат — дай денег.
жалко — пользуйся классикой.
они работают, работают шустрей классических програм. Кушают мало.
да, падают, да интерфейс страшный. Ну и что?
потом её увидел приятель, взял, потом ещё кто-то попросил. Потом я программу с кратким руководством выложил в инет.
хочешь сертификат — дай денег.
жалко — пользуйся классикой.
Нюанс в том, что не все и не всегда продают хорошие вещи за деньги. Есть люди, которые пишут хорошие (да, зачастую достаточно нишевые, и чаще всего мелкие) программы и раздают всем желающим бесплатно, т.е. даром, на условиях тех же GPL, MIT, BSD и т.д. лицензий. Вот, собственно, независимый разработчик — это не обязательно тот, кто независимой разработкой деньги зарабатывает. Это иногда еще и талантливый энтузиаст, которого в текущем положении ставят раком в виде «не только потрудись софтинку написать, но еще и денег занести не забудь».
мне кажется, что ваша ошибка в предположении, что задача разработчика ОС сделать хорошо _всем_. А это совсем не так — «проблемы индейцев шерифа не волнуют». Цель вендора — чтобы его ОС и ПО покупали. Если для обеспечения (может даже только видимой) безопасности требуется ущемить неких энтузиастов (к-рые, BTW, т.к. делают это чисто для «фана», и своих пользователей вряд ли будет поддерживать на регулярной основе) — why not? Еще раз: ни вендора, ни меня, как потребителя, не очень волнуют проблемы некоего талантливого энтузиаста, к-рый пишет что-то «for fun».
Тем более, если его проблемы — это просто необходимость для пользователя лишний раз подтвердить согласие на риски и установку его ПО.
Тем более, если его проблемы — это просто необходимость для пользователя лишний раз подтвердить согласие на риски и установку его ПО.
Ну, если разработчика заставлять финансово страдать, то можно прийти к варианту Apple экосистемы — там разработчики платят деньги, но и в обмен пользователи получают не тысячи вариантов, а один-два, и, зачастую, оба платные.
То есть за повышенный порог входа для разработчиков придётся платить пользователям.
То есть за повышенный порог входа для разработчиков придётся платить пользователям.
мне кажется, что ваша ошибка в предположении, что задача разработчика ОС сделать хорошо _всем_.
Ай нет, у меня некоторое когнитивное несоответствие. С одной стороны — Балмер, рассекающий по сцене кругами с выкриками «Developers! Developers!» и, без преувеличения, тонны полезного тулинга от «майков» за последние лет 5-10. А с другой — цифровое гетто внутри выпускаемой теми же «майками» операционной системы, со всеми этими ничего не значащими подписями, которые откровенно преследуют ровно одну цель — срубить с разработчика бабла, причем в слабоадекватных количествах.
С одной стороны гранты на Azure для открытых проектов и новая политика гитхаба, а с другой — не забудьте занести тыщу баксов в год, чтобы оно имело шанс установиться. При этом за эту «тыщу» еще и лютая гора геморроя и неработающий сервис.
Собственно, оно бы и ничего, если бы а) оно имело бы какой-то смысл, б) оно хотя бы корректно работало. А так — разработчик приходит ровно к 1 выводу: либо монетизируй, чтобы хоть как-то оправдать расходы на подпись, либо не мучай попу. Ну, такое себе.
И еще раз повторюсь, я совершенно не питаю иллюзий насчет того, что проприетарный коммерческий продукт может преследовать иные цели, кроме извлечения коммерческой прибыли. Я просто выражаю некоторую озадаченность когнитивным диссонансом, который вызывает сравнение пиара вида «все для разработчиков» с реальным гетто внутри той же экосистемы.
Как по мне, всё логично и последовательно.
MS не нужны разработчики как предприниматели и продавцы своего продукта, а нужны как рабочая сила в отделах автоматизации больших предприятий.
Нужно, чтобы разработчики научились сами, дома, за свой счёт (на пиратских или бесплатных инструментах), пришли работать, а на рынке кроме Windows-программистов по большей части никого другого нет. Вот тогда MS возьмёт денег с предприятий, и даже не за средства разработки и серверы (хотя SQL Server и Windows Server 2020 не дёшевы), а больше за парк клиентских машин и офисов, на которых запускаются поделки windows-программистов.
Поскольку Azure пиратить невозможно, как Visual Studio или SQL Server, приходится бесплатно раздавать под некоторые условия, чтобы люди учились.
MS не нужны разработчики как предприниматели и продавцы своего продукта, а нужны как рабочая сила в отделах автоматизации больших предприятий.
Нужно, чтобы разработчики научились сами, дома, за свой счёт (на пиратских или бесплатных инструментах), пришли работать, а на рынке кроме Windows-программистов по большей части никого другого нет. Вот тогда MS возьмёт денег с предприятий, и даже не за средства разработки и серверы (хотя SQL Server и Windows Server 2020 не дёшевы), а больше за парк клиентских машин и офисов, на которых запускаются поделки windows-программистов.
Поскольку Azure пиратить невозможно, как Visual Studio или SQL Server, приходится бесплатно раздавать под некоторые условия, чтобы люди учились.
MS не нужны разработчики как предприниматели и продавцы своего продукта, а нужны как рабочая сила в отделах автоматизации больших предприятий.
Не совсем так. По общему движению видно, что им три вида разработчиков нужны:
1. Бизнес-автоматизаторы, чтобы продвигать продажи Windows-экосистемы в бизнесы.
2. Разработчики тонн говнософта, сравнимых с гуглоплеевскими, для Windows-Store.
3. Разработчики облачных приложений, чтобы чем-то платно нагрузить Azure.
С первыми почти все в порядке, но их достаточно жестко склоняют к лицензированию через подписи скриптов и все вот это.
Со вторыми все не особо в порядке, т.к. их позиционируют как уже работающий источник монетизации, не имея чего-то серьезного предложить взамен. Если Apple предлагает «илитарность», «унитарность» и «высоко-платежеспособное комьюнити» и просит взамен серьезных денег, а Google — массовость платформы за деньги небольшие… Микрософт ни платежеспособности, ни особой массовости предложить не может. В самом деле, вы много человеков видели, которые бы Windows-Store пользовались? Все а) привыкли качать ручками, б) не привыкли платить, в) выпиливают маркетинговые интерфейсы из винды и ходят с транспарантами, требуя их убрать вообще. Т.е. маркетинговой и торговой платформы у Майков, по факту, нет. Вообще не понятно, за что деньги платить.
А у Azure-разрабов все действительно хорошо. Вот тут не поспоришь.
Больно всем остальным. И вся вот эта хрень с подписями подается под соусом, мол, «ради безопасности». А на самом деле — строго с одной целью: «Загнать разрабов десктопного софта в стойло Windows-Store, ибо нефиг мимо нас деньги получать». Времена меняются, Микрософт остается.
При этом хрен бы с ним, казалось бы. Почему бы, собственно, и не через Windows-Store… Но:
1. Он очень куцый по «умелкам». 90% софта не могут распространяться через Windows-Store. Ну просто физически.
2. У него никакая релевантность, никакого маркетинга, ничего. А если внимательно взглянуть на содержимое — может и удар прихватить. Чего только сборки Open/LibreOffice по 200у.е. в промышленных количествах стоят…
Ну, короче, «независимых разработчиков» пинками загоняют в стойло, в котором очень дурно пахнет, сопровождая это криками «Разработчики! Разработчики! Мы любим разработчиков! Все для разработчиков!»
Вы не подумайте, я не осуждаю. Это нормальное поведение коммерческой конторы. Я просто говорю про то, что независимым разработчикам (очень пафосно звучит, самому не нравится, просто лень подбирать более релевантное определение) действительно больно. Раньше было менее больно, а теперь — более.
Эппл и Гугл — они ровно такие же, с одним нюансом: у них гетто стало огораживаться после того, когда внутри обжились и оценили преференции от нахождения внутри. Майки же сначала ставят забор, а уже внутри постепенно строят гетто, куда громкими выкриками пытаются заманить будущих жителей. «Нивзлитит».
2. Разработчики тонн говнософта, сравнимых с гуглоплеевскими, для Windows-Store.Микрософт забил на свой стор и куча мелких софтин (именно как бизнесы, а не как тулзы для гиков) ему вообще не нужна. Достаточно, чтобы стим/эпик продавали игры, а гиганты типа Adobe/Autodesk продавали свои пакеты.
3. Разработчики облачных приложений, чтобы чем-то платно нагрузить Azure.Нет никаких «облачных azure-приложений» для пользователей.
Azure продают корпорациям и те строят на нём свою инфраструктуру (например, у нас телеметрия и мониторинг для всех внутренних сервисов и приложений), используют iops-ы/терабайты для хранения файлов, хостинг всяких sharepoint'ов.
Второй вариант использования Azure — большие компании вроде условного Netflix-а и облачного гейминга. Тут Azure для пользователя скрыт за ширмой другого бренда.
Каким-то мелким девелоперам вообще нет смысла продавать Azure, больше возни. Разве что в маркетинговых целях, чтобы все умели с ним работать.
Микрософт забил на свой стор и куча мелких софтин (именно как бизнесы, а не как тулзы для гиков) ему вообще не нужна. Достаточно, чтобы стим/эпик продавали игры, а гиганты типа Adobe/Autodesk продавали свои пакеты.
Вот с этим могу согласиться только частично. То, что выглядит он ровно так, что на него как будто забили — это факт. Помойка та еще.
Насчет «гиганты типа Adobe/Autodesk продавали свои пакеты» — это прямо в точку.
чтобы стим/эпик продавали игры
А вот тут прямо мимо. Суммы, которые на их платформе уходят стиму и эпику майки отлично видят. Именно поэтому прямо сейчас зашел в микрософт стор, и прямо на полэкрана увидел «Скидки 50%: Age of Empires, Halo, Ori, Forza, Kindom Come...etc». Стим, эпик & Ко. майкам поперек горла и неизбежное зло. Избавиться и задавить на корню нельзя, т.к. пользователи и ведущая игровая платформа, поддерживать миллион хотелок игроделов приходится забесплатно и видя при этом, кому уходят деньги, а сделать с этим ничего решительно нельзя. Плачут, колются, продолжают жрать кактус, периодически предпринимают достаточно жалкие попытки переломить ситуацию (к слову, та же Steam OS — прямое следствие одной из таких попыток и пугало именно для майков).
А с тысячами говнософта — тут, похоже, они сами еще не определились, надо оно им, или нет. Когда хотели на мобильный рынок пролезть — было заметно, что надо. Сейчас, вроде, и UWP хоронят, и мобильная платформа в коме. При этом сами майки заявляют, что «ничего еще не закончено, мы обязательно вернемся».
Нет никаких «облачных azure-приложений» для пользователей.
Azure продают корпорациям и те строят на нём свою инфраструктуру
Второй вариант использования Azure — большие компании вроде условного Netflix-а и облачного гейминга
Каким-то мелким девелоперам вообще нет смысла продавать Azure, больше возни
А вот тут — ай, мимо. Почти 12млрд. за последний квартал им в Azure далеко не только «крупные акулы бизнеса» занесли. Есть такая ниша — когда wordpress'а уже не хватает, а цельный keubernettes-кластер все еще дороговато. И вот в этом сегменте майки очень активны вплоть до демпинга. Они хотят этот сегмент.
чем один раз влететь на шифровальщикаВы и так можете в него влететь, и цп вас от этого не защищает даже на 30%
И, если вендор ПО делает сложнее вам, но безопаснее мне, честь ему и хвалаНу как сказать… больше похоже на: чтобы защитить вас от переедания, вводим платные талоны на продукты.
натянутые донельзя аналогии. Обратите внимание, что жалобы в 1ую очередь от разрабов — а не от пользователей.
А с чего пользователям жаловаться? Они скачали прожку, попытались запустить, получили страшное предупреждение, испугались, удалили программу и порадовались: «какая молодец система, защитила меня бедного от злых вирусов, троянов и куков».
Так. И какие проблемы у пользователя? Никаких. Отлично — то, о чем я и пишу: система нацелена на упрощение жизни пользователя. Я — за.
У пользователя проблемы такие, что его отпугивают от совершенно добросовестного софта, который мог бы упростить этому пользователю жизнь. При этом не обеспечивая защиты от реальных зловредов. То, что пользователь этого не осознаёт, лишь усугубляет проблему.
Ну тогда давайте вообще пользователю запретим комп включать, и судя по вашей логике у пользователя еще меньше проблем станет и вообще жизнь наладится.
«Безопасности не бывает много». Поэтому сначала нужно на ровном месте запугать всех рядовых пользователей до икоты, а потом надеть на них намордник. То-то всем становится весело, то-то хорошо.
сначала к драйверам прикрутили эти подписи, потом стало невозможным установить неподписанный драйвер(некоторые даже в тестовом режиме не ставятся, я так намучился со звуковой картой от zoom). теперь так же за софт взялись? а как быть с open source?
с другой стороны, есть всякий софт для «левой» подписи драйверов, думаю, что и тут так же будет.
с другой стороны, есть всякий софт для «левой» подписи драйверов, думаю, что и тут так же будет.
Microsoft монополизирует распространение софта для Windows, потому что им не дают покоя лавры App Store и Google Play. Это проявляется везде, даже в VS Code, где кастомные сборки редактора не могут использовать репозиторий плагинов Microsoft.
Для подписи драйвера, как писали выше, уже давно нужен EV сертификат. Но сейчас этого мало, технически нужно этот сертификат просто подтвердить, подписав им болванку от MS, а непосредственно подпись драйвера осуществляется на серверах MS их сертификатом.
Open Source, если говорить о third-party, либо уже подписан издателем, либо может быть подписан вашей собственной подписью перед упаковкой в инсталлятор. Никаких проблем с Open Source по поводу цифровой подписью не наблюдал ни разу.
Другое дело, конечно, если вы пытаетесь использовать готовый Open Source продукт без подписи, но в этом случае если вы пользователь — проверяете бинарники на VirusTotal и говорите SmartScreen, что всё в порядке.
Если вы разработчик Open Source и выпускаете в мир неподписанный софт — вы ведь всё равно не ожидали прибыли от продукта. Если выпускаете подписанный свежим сертификатом — просто выжидаете время, пока количество установок не перевалит значения, достаточного для того, чтобы SmartScreen перестал на ваш сертификат реагировать.
Другое дело, конечно, если вы пытаетесь использовать готовый Open Source продукт без подписи, но в этом случае если вы пользователь — проверяете бинарники на VirusTotal и говорите SmartScreen, что всё в порядке.
Если вы разработчик Open Source и выпускаете в мир неподписанный софт — вы ведь всё равно не ожидали прибыли от продукта. Если выпускаете подписанный свежим сертификатом — просто выжидаете время, пока количество установок не перевалит значения, достаточного для того, чтобы SmartScreen перестал на ваш сертификат реагировать.
Но массовый пользователь от этого очень даже выиграл. В эру до смарт скрина было намного легче попасться на удочку, когда скачал фэйковый установщик известной программы и установил своими руками троян. С появлением скрина хотя бы можно заметить, что skype.exe то не настоящий, потому что без подписи и сходить перепроверить оттуда ли ты его скачал. Со всеми этими фишками польза от антивирусов резко упала, потому что 99% массового софта с подписями и ты понимаешь, что ставишь софт от производителя, а не от васяна.
UFO just landed and posted this here
Отличный коммент. Самому лень такое исследование было сделать со скриншотами, потому не стал про это упоминать тут. Вот оно все лицемерие всей индустрии сертификатов, в том виде, в котором она есть на данный момент.
Т.е. вы предполагаете, что вот эти ребята — installpack.net — распроcтраняют вирусы? Или таки они просто занимаются не очень одобряемой упаковкой и без того доступного ПО в свои инсталлеры с добавлением сверху всякой «пурги» типа Я браузера и всяких «ускорителей» инета? Во 2ом случае они просто не совсем чистые на руку предприниматели, но никак не malicious guys.
ps. прошу прощения, но не смогу оперативно отвечать на злободневную тему — защитники конечных пользователей решили, что я — неправильный пользователь. :-D
ps. прошу прощения, но не смогу оперативно отвечать на злободневную тему — защитники конечных пользователей решили, что я — неправильный пользователь. :-D
В 2012м я сделал бесплатно сертификат от нортона (на сайте нортона).
Делал специально, чтобы Windows определял мой софт как от «благочистивого» разработчика.
С тех пор и подписываю им.
Специально сейчас проверил самые старые установщики и .exe — смарт-скрин на них не ругается.
Вопрос, это мне сильно повезло и следует беречь сертификат как зеницу ока, или же я что-то делаю(проверяю) не так?
Делал специально, чтобы Windows определял мой софт как от «благочистивого» разработчика.
С тех пор и подписываю им.
Специально сейчас проверил самые старые установщики и .exe — смарт-скрин на них не ругается.
Вопрос, это мне сильно повезло и следует беречь сертификат как зеницу ока, или же я что-то делаю(проверяю) не так?
Обычно сертификат выдаётся на 1-3 года, после чего превращается в тыкву и годится разве что для подписи драйверов без штампа времени, а уж о бесплатной раздаче вообще не помню.
Если софт не содержит каких-либо подозрительных системных вызовов, т.е. в чистом виде прикладной и простой с т.з. различных эвристик антивирусов, то и без всяких сертификатов его детектить не будут.
Для того, чтобы избежать подобной ситуации достаточно:
1) Всё-таки приобрести сертификат. Стоит не такие уж космические деньги и даёт определённую защиту от взлома.
2) Потратить немного усилий на тестирование своей программы. По моему опыту достаточно одной-двух недель установок релизной версии программы для того, чтобы сертификат успел засветиться как «безвредный». Репутация рассчитывается не по положительным отзывам, а по комбинации количества установок и количества жалоб.
Не исключено, что что-то изменилось за пять лет (когда я первый и последний раз столкнулся со впервые выпущенным для компании сертификатом), но тогда это работало именно так. Неделю видел смарт-скрин при установке, после этого попустило. Кроме меня (разработчика) это приложение устанавливал только тестировщик. Т.е. количество уникальных машин какого-то значения не имело — только количество установок и/или отсутствие жалоб в течении какого-то времени после первого запуска инсталлятора со свежевыпущенным сертификатом.
1) Всё-таки приобрести сертификат. Стоит не такие уж космические деньги и даёт определённую защиту от взлома.
2) Потратить немного усилий на тестирование своей программы. По моему опыту достаточно одной-двух недель установок релизной версии программы для того, чтобы сертификат успел засветиться как «безвредный». Репутация рассчитывается не по положительным отзывам, а по комбинации количества установок и количества жалоб.
Не исключено, что что-то изменилось за пять лет (когда я первый и последний раз столкнулся со впервые выпущенным для компании сертификатом), но тогда это работало именно так. Неделю видел смарт-скрин при установке, после этого попустило. Кроме меня (разработчика) это приложение устанавливал только тестировщик. Т.е. количество уникальных машин какого-то значения не имело — только количество установок и/или отсутствие жалоб в течении какого-то времени после первого запуска инсталлятора со свежевыпущенным сертификатом.
Если всё работает так как вы описываете — то система репутации вообще полный бред и тупость.
UFO just landed and posted this here
Пример по дотнету.
Допустим у вас большое приложение из многих библиотек. Защита вашего приложения живёт в одной из них. Обфускатор, конечно, помогает, но гарантии от получения компилирующихся исходников не даёт — вопрос желания.
В конце-концов бинарник можно декомпилировать в IL. Если взломщик обладает навыками работы с IL — вариант вполне рабочий.
Или даже прямая правка бинарника без декомпиляции. Чтобы заменить какую-нибудь строку, например.
В общем взломщик обходит защиту в бинарнике любым способом, получает взломанную библиотеку, подкладывает в рабочую папку приложения с заменой оригинала и получает свободно распространяемый бинарник.
Если все библиотеки вашего приложения подписаны — подключить модифицированный бинарник без подписи дотнет не даст. И даже подпись другим сертификатом не пройдёт — компоненты, которые ссылаются на модифицированную библиотеку откажутся загружать её, если Public Key не соответствует оригиналу.
Т.е. остаётся вариант полной пересборки всех бинарников вашего приложения без подписи или с подписью другим сертификатом.
Если даже бинарник редактировался без декомпиляции, то модифицированный файл не пройдёт проверку подписи по контрольной сумме.
Не сильно вдавался в тему сложно ли обойти защиту от загрузки библиотеки с несоответствующей подписью, только знаю, что легальных способов для этого дотнет не предоставляет.
Кроме того, на моей памяти есть один очень давний случай, когда в процессе разбирательства с проблемами у клиента была обнаружена пересобранная не нашей компанией библиотека. Сразу после этого директор наконец-то решился «раскошелиться» на сертификат, до этого никакие аргументы его не пронимали.
Допустим у вас большое приложение из многих библиотек. Защита вашего приложения живёт в одной из них. Обфускатор, конечно, помогает, но гарантии от получения компилирующихся исходников не даёт — вопрос желания.
В конце-концов бинарник можно декомпилировать в IL. Если взломщик обладает навыками работы с IL — вариант вполне рабочий.
Или даже прямая правка бинарника без декомпиляции. Чтобы заменить какую-нибудь строку, например.
В общем взломщик обходит защиту в бинарнике любым способом, получает взломанную библиотеку, подкладывает в рабочую папку приложения с заменой оригинала и получает свободно распространяемый бинарник.
Если все библиотеки вашего приложения подписаны — подключить модифицированный бинарник без подписи дотнет не даст. И даже подпись другим сертификатом не пройдёт — компоненты, которые ссылаются на модифицированную библиотеку откажутся загружать её, если Public Key не соответствует оригиналу.
Т.е. остаётся вариант полной пересборки всех бинарников вашего приложения без подписи или с подписью другим сертификатом.
Если даже бинарник редактировался без декомпиляции, то модифицированный файл не пройдёт проверку подписи по контрольной сумме.
Не сильно вдавался в тему сложно ли обойти защиту от загрузки библиотеки с несоответствующей подписью, только знаю, что легальных способов для этого дотнет не предоставляет.
Кроме того, на моей памяти есть один очень давний случай, когда в процессе разбирательства с проблемами у клиента была обнаружена пересобранная не нашей компанией библиотека. Сразу после этого директор наконец-то решился «раскошелиться» на сертификат, до этого никакие аргументы его не пронимали.
Тут взломщику поможет библиотека манипулирования сборками Mono.Cecil.
Она создаёт объектную модель сборки, в которой можно добавлять, редактировать и удалять типы (классы), методы, поля, инструкции IL-кода, ссылки (references). Затем модель сериализуется обратно в бинарный файл. Процесс достаточно надёжный, на нём работает Mono, PostSharp и Fody. Достаточно будет найти и заменить strong name reference на обычную, по имени DLL.
Она создаёт объектную модель сборки, в которой можно добавлять, редактировать и удалять типы (классы), методы, поля, инструкции IL-кода, ссылки (references). Затем модель сериализуется обратно в бинарный файл. Процесс достаточно надёжный, на нём работает Mono, PostSharp и Fody. Достаточно будет найти и заменить strong name reference на обычную, по имени DLL.
Оригинальное решение, не сталкивался.
Насколько я понял — это позволяет подменить reference с подписанной оригинальной библиотеки на неподписанную взломанную. Но разве .Net позволяет референсить неподписанные библиотеки из подписанных?
Компилятор такого точно не позволяет, или в runtime дополнительной проверки нет?
Хотя, при таких возможностях Cecil подозреваю, что можно заменить один strong name reference на другой, но для этого всё-таки придётся чем-нибудь подписать взломанную библиотеку.
Если мне не изменяет память, то в рантайме проверка всё же есть — Assembly.Load не позволит загрузить неподписанную библиотеку в AppDomain, созданный подписанным exe.
Насколько я понял — это позволяет подменить reference с подписанной оригинальной библиотеки на неподписанную взломанную. Но разве .Net позволяет референсить неподписанные библиотеки из подписанных?
Компилятор такого точно не позволяет, или в runtime дополнительной проверки нет?
Хотя, при таких возможностях Cecil подозреваю, что можно заменить один strong name reference на другой, но для этого всё-таки придётся чем-нибудь подписать взломанную библиотеку.
Если мне не изменяет память, то в рантайме проверка всё же есть — Assembly.Load не позволит загрузить неподписанную библиотеку в AppDomain, созданный подписанным exe.
UFO just landed and posted this here
Мне не нравятся приложения, требующие какой-либо установки.
Это простой редактор изображений? Нет его нельзя просто скачать и запустить, надо установить, при этом наверняка инсталятор положит что-то в реестр, cделает файлы некоторых расширений открываемыми собой, наустанавливает мне софта мейл ру, и конечно-же не подумает подчистить за собой при удалении.
Лучшее, что я видел, приложение состоящее из одной exe. Оно просто запускается и работает.
Это простой редактор изображений? Нет его нельзя просто скачать и запустить, надо установить, при этом наверняка инсталятор положит что-то в реестр, cделает файлы некоторых расширений открываемыми собой, наустанавливает мне софта мейл ру, и конечно-же не подумает подчистить за собой при удалении.
Лучшее, что я видел, приложение состоящее из одной exe. Оно просто запускается и работает.
UFO just landed and posted this here
Я когда начал распространять своё приложение, так и сделал сначала. Был обычный exe файл упакованный в zip архив. После скачивания, предполагалось что пользователь распакует его в удобное для него место. После запуска приложение создавало в той же директории папку с логами, файл с настройками и т.д. Всё создавалось в той же папке из соображений, что если пользователь захочет удалить программу, то он просто удаляет папку.
Но, по мере того как всё больше людей стало пользоваться моей программой столкнулся с проблемой, каждый третий норовит распаковать в папке Program Files. А в современных версиях Windows, по умолчанию, там писать нельзя. Поэтому как то само собой и перешёл на инсталятор, а все настройки храню в ProgramData.
Но, по мере того как всё больше людей стало пользоваться моей программой столкнулся с проблемой, каждый третий норовит распаковать в папке Program Files. А в современных версиях Windows, по умолчанию, там писать нельзя. Поэтому как то само собой и перешёл на инсталятор, а все настройки храню в ProgramData.
Здесь есть в меру простое решение проблемы: если нет доступа на запись в текущую папку, надо сругаться и спросить, устроит ли пользователя хранение настроек и логов в такой-то папке (ProgramData или AppData — в зависимости от того, нужны вам настройки этой программы общие для компьютера или отдельные для пользователя).
Тогда мы возвращаемся к вопросу о том, что в системе останется мусор после удаления папки с программой. Т.к. папка с логами и настройками будет находиться в другом месте, да и запись об этой папке где то должна храниться. А пользователь, вряд ли вручную будет систему подчищать.
Поэтому и получается, что проще инсталятор сделать, и в нём при удалении прописать очистку.
Поэтому и получается, что проще инсталятор сделать, и в нём при удалении прописать очистку.
UFO just landed and posted this here
Портабельные программы нельзя в Program Files класть. Они всегда пишут только в своей директорией, а это Windows категорически не нравится. Хотя казалось бы что это самое безопасное поведение.
Я бы не был так категоричен по поводу
Они всегда пишут только в своей директориейТут как автор программу реализует и какие данные пишутся. Это вполне может быть и профиль пользователя, в который все нормально пишется.
UFO just landed and posted this here
Вы не правы. Разрабы пришли ДО того как NT получил распространение. И исходили из той модели, которая тогда была в 9x. А потом просто слишком много legacy было, чтобы что-то менять.
UFO just landed and posted this here
Серьёзные производители софта, тем не менее, давным-давно выполняют эти требования. Более того, в мире *nix-подобных систем, в общем-то, всё то же самое. Обычный пользователь может писать в свою домашнюю директорию, но не может из неё запускать. Правда, ещё tmp может быть.
Куча серьезных производителей софта клали на эти требования. Например гугл с хромом.
В мире *-nix так было всегда. Если бы так было изначально в винде — никто бы не бухтел и все бы так изначально и делали.
Ну и вы ошибаетесь — обычный пользователь без проблем может запускать софт из своего домашнего каталога. Не скажу за все никсы, то в линуксе точно может.
В мире *-nix так было всегда. Если бы так было изначально в винде — никто бы не бухтел и все бы так изначально и делали.
Ну и вы ошибаетесь — обычный пользователь без проблем может запускать софт из своего домашнего каталога. Не скажу за все никсы, то в линуксе точно может.
Ну и вы ошибаетесь — обычный пользователь без проблем может запускать софт из своего домашнего каталога. Не скажу за все никсы, то в линуксе точно может.
Собственно, опциями монтирования регулируется. Тут скорее корректнее будет «в линуксе опциями монтирования такой результат достигается на раз-два, но, из-за моды на юзерспейсные установщики, дефолтное поведение на данный момент, к сожалению, монтирование хомяка без noexec-опции»
UFO just landed and posted this here
Не заметил идентичности.
Linux имеет:
1. Опцию монтирования noexec, которая по факту монтирования позволяет запретить исполнение файлов в разделе вне зависимости и без исправления как таковых любых прав/параметров и т.д. самой файловой системы. К слову, дефолтный noexec на хомяка в последнее время не ставят — это да. А на флешки — вполне себе, т.е. уже польза.
2. Раздельные права на исполнение и чтение файла как атрибуты ФС. Т.е. а) можно разрешить читать, копировать, whatever файл, не позволяя запуск, б) можно разрешить исполнение, не позволяя чтение.
3. AppArmor/SELinux — дополнительный слой, позволяющий дополнительно ограничивать права.
В Windows, как я понимаю, аналогом AppArmor/SELinux можно частично считать UAT или как оно там зовется. А аналоги первых двух — как с ними?
В общем, совершенно не так же, и абсолютно не ровно.
Linux имеет:
1. Опцию монтирования noexec, которая по факту монтирования позволяет запретить исполнение файлов в разделе вне зависимости и без исправления как таковых любых прав/параметров и т.д. самой файловой системы. К слову, дефолтный noexec на хомяка в последнее время не ставят — это да. А на флешки — вполне себе, т.е. уже польза.
2. Раздельные права на исполнение и чтение файла как атрибуты ФС. Т.е. а) можно разрешить читать, копировать, whatever файл, не позволяя запуск, б) можно разрешить исполнение, не позволяя чтение.
3. AppArmor/SELinux — дополнительный слой, позволяющий дополнительно ограничивать права.
В Windows, как я понимаю, аналогом AppArmor/SELinux можно частично считать UAT или как оно там зовется. А аналоги первых двух — как с ними?
В общем, совершенно не так же, и абсолютно не ровно.
UFO just landed and posted this here
Разрешите немножечко попридираться:
В линухе права на запуск файла и на просмотр содержимого запускаемого файла — сущности различные. Т.е. вы можете дать право запускать без права посмотреть, что внутри. Иногда это полезно, и всегда забавно.
А вот это искренне жаль и прямо сильно не хватает. Собственно эпидемию авторанов мы все помним. Ну и, собственно, абсолютная гарантия, что с конкретного носителя точно-точно ничего не запустится, как ни мудри — это полезно. А возможность перемонтировать так, чтобы «было можно», запустить, и снова перемонтировать, чтобы «было нельзя» — это прикольно и приятно. При этом схема простая, «в лоб», и работает для тех же флешек на выходе лучше, чем любые «проактивные защиты».
Не совсем то же самое. В Windows отсутствует простая и при этом стопудово гарантированная возможность запретить исполнение любых файлов из хомяка, проигнорировав проблемы кривого софта. В Linux такая возможность есть.
Т.е. в Linux не работает из-за кривого софта, а в Windows — и с прямым тоже не работает.
права доступа на запуск и просмотр содержимого каталога отдельные
В линухе права на запуск файла и на просмотр содержимого запускаемого файла — сущности различные. Т.е. вы можете дать право запускать без права посмотреть, что внутри. Иногда это полезно, и всегда забавно.
Опций монтирования в Windows нет
А вот это искренне жаль и прямо сильно не хватает. Собственно эпидемию авторанов мы все помним. Ну и, собственно, абсолютная гарантия, что с конкретного носителя точно-точно ничего не запустится, как ни мудри — это полезно. А возможность перемонтировать так, чтобы «было можно», запустить, и снова перемонтировать, чтобы «было нельзя» — это прикольно и приятно. При этом схема простая, «в лоб», и работает для тех же флешек на выходе лучше, чем любые «проактивные защиты».
А про ровно тоже самое я писал к тому, что ни в Linux, ни в Windows нельзя просто взять и запретить запуск ПО (любыми средствами) в домашнем каталоге, так как это сломает кучу кривого софта.
Не совсем то же самое. В Windows отсутствует простая и при этом стопудово гарантированная возможность запретить исполнение любых файлов из хомяка, проигнорировав проблемы кривого софта. В Linux такая возможность есть.
Т.е. в Linux не работает из-за кривого софта, а в Windows — и с прямым тоже не работает.
UFO just landed and posted this here
Ну вот собственно, из дефолтной разницы — с флешек в линухе ничего не запускается.
Так прям ничего не запускается? Если я сделаю двойной клик по jpg-фотографии, она не откроется дефолтным вьювером? А по html-файлу? А по python-скрипту?
Вот так прям и не запускается. Просмотр jpeg-фотографии — это не исполнение этой фотографии. Просмотрщик откроется. HTML-файл также неисполняемая вещь, браузером откроется. А python-скрипт транслируется интерпретатору и исполняет инструкции, содержащиеся в файле — он не запустится. Равно как и sh-скрипт, скрипт на любом другом языке или тупо бинарный исполняемый файл. С бинарем прямо вообще никак, а транслируемые скрипты (например, python-файл) — только ручками запустив интерпретатор и скормив скрипт внутрь. Согласитесь, это сильно отличается от «сунул флешку, и там само что-то запустилось» и уж тем более от «кликнул в ОфигенныйФильмСмотретьБесплатноБезРегистрацииИСМС.mp4.py, а у меня все зашифровалось».
Но в чём разница для оболочки? Что отдать jpg-файл вьюверу, что py-файл интерпретатору — это не одно и то же? Или там где-то в ассоциациях искусственно зашито, что считается исполнением, а что нет?
Но в чём разница для оболочки? Что отдать jpg-файл вьюверу, что py-файл интерпретатору — это не одно и то же? Или там где-то в ассоциациях искусственно зашито, что считается исполнением, а что нет?
Вы не просекли фишку. Ассоциации — это привязка «что делать с файлом» на основании его расширения. Ну вот в ассоциациях на python-скрипт в линуксе будет текстовый редактор, который будет радостно открываться по дубль-клику — «инфа соточка». Права на запуск — это отдельный атрибут файловой системы. Т.е. интерпретатору python-скрипт пойдет в 2 случаях:
1. При тупом запуске, если в файловых атрибутах конкретного файла разрешено исполнение для того пользователя/группы, который его «тычет».
2. Если ручками запустить python и отдать ему этот скрипт.
А по дубль-клику на файл просто открывается редактор/просмотрщик, ваша любимая IDE от Jetbrains и пофиг вообще чо, не предполагающее исполнения.
Согласитесь, сильно отличается от «тупо кликнул по файлу МоеЛюбимоеПорно.avi.py» и получил шифровальщик.
Вся суть драмы: в линухе есть раздельные понятия «исполнение» и «просмотр/редактирования». Они разные, по-разному выглядят, по-разному работают, регулируются раздельными ограничениями и принципиально по-разному устроены. В винде есть «расширение файла» и запуск регулируется файловыми ассоциациями вида «exe, com — запускать, bat, cmd, ps — скармливать соответствующему интерпретатору, jpg, png — открывать просмотрщиком фото», а поверх этого разветвленная эвристика…
Ну, в общем, в этом плане nix-подобные вещи сильно более аккуратные и несколько умнее спроектированы (заметьте, именно в этом плане, не являюсь ярым адептом и «мамкиным противостоятелем Виндоус», веселых моментов и в винде, и в линухе хватает, говорю ровно про этот момент, который лично мне стоил, в свое время, достаточно большого количества нервов).
Немного стало понятнее. Двойной клик по файлу работает по-разному, в зависимости от наличия атрибута 'x'.
FAT32 флешку можно смонтировать с опцией exec, и абсолютно на всех файлах появится этот атрибут, или с опцией noexec, тогда его не будет вообще ни каком файле.
FAT32 флешку можно смонтировать с опцией exec, и абсолютно на всех файлах появится этот атрибут, или с опцией noexec, тогда его не будет вообще ни каком файле.
Немного стало понятнее. Двойной клик по файлу работает по-разному, в зависимости от наличия атрибута 'x'.
Справедливости ради, нет. Двойной клик по файлу всегда работает одинаково — открытие файла на простмотр/редактирование (aka обработка файловых ассоциаций по расширению файла). Т.е. по дубль-клику запуск файла не произойдет. Фильм — посмотрите, документ — поредактируете, скрипт/бинарь — фиг. Для запуска/кормления интерпретатору придется приседать несколько больше (давить правую кнопку мыши и все такое). Короче, никак не спутаешь.
FAT32 флешку можно смонтировать с опцией exec, и абсолютно на всех файлах появится этот атрибут, или с опцией noexec, тогда его не будет вообще ни каком файле.
А вот это мимо совсем. Атрибута «исполняемый» у файла нет. Это «права на исполнение» на уровне файловой системы. RWX (Read,Write,eXecute) — «атрибут Х» вы правильно нашли. Просто нашли вы его не там. Этот атрибут — атрибут прав доступа на файл на уровне файловой системы.
Собственно, параметра монтирования файловой системы exec не существует. Есть только параметр noexec, который означает «игнорировать X-права на файлах», т.е. это защита уровня файловой системы, драйвер ФС просто тупо отдает 0 в наборе прав на месте X, вне зависимости от того, что в файловой системе указано.
В связи с этим для «неродных» файловых систем все это может только маппиться, как, например, с NTFS — ntfs-права «чтение» и «запись» транслируются для ядра в r и w соответственно. ЕМНИП, «чтение и исполнение» ntfs в линуксовый x не транслируется (тут могу ошибаться, не проверял, т.к. в любом случае все «неродные» файловые системы не предполагают возможность исполнения файла).
С fat32 еще проще. Сама vfat права хранить тупо не умеет, поэтому они откатываются к «дефолтам» rwxr--r--, т.е. «исполнить» что-либо с fat32-раздела — это в принципе достаточно нетривиальная задача. И хоть вы умонтируйтесь, fat32 права на исполнение не получит. Приседайте с umask.
Понятно, почему в Windows так не будет.
Когда-то давно файлы запускались с CD-ROM, ломать это нельзя. В enterprise-среде файлы запускаются с сетевых шар, тут тоже вопрос с атрибутами.
Если вернуться на 10 комментов назад к изначальной проблеме, то защита линукса строится на том, чтобы пользователь задолбался включать запускаемость, а значит, при приходе линукса в массы эту всю фигню быстро автоматизируют.
Например, web-инсталлеры хрома, гога или стима представляют собой маленький exe-шник, запускаемый одним кликом, который всё докачивает. Юзеры либо привыкнут и будут на автомате скачивать файл, ставить +x и запускать правой кнопкой, либо это всё будет автоматизированно в «новом удобном браузере Амиго».
Когда-то давно файлы запускались с CD-ROM, ломать это нельзя. В enterprise-среде файлы запускаются с сетевых шар, тут тоже вопрос с атрибутами.
Если вернуться на 10 комментов назад к изначальной проблеме, то защита линукса строится на том, чтобы пользователь задолбался включать запускаемость, а значит, при приходе линукса в массы эту всю фигню быстро автоматизируют.
Например, web-инсталлеры хрома, гога или стима представляют собой маленький exe-шник, запускаемый одним кликом, который всё докачивает. Юзеры либо привыкнут и будут на автомате скачивать файл, ставить +x и запускать правой кнопкой, либо это всё будет автоматизированно в «новом удобном браузере Амиго».
Понятно, почему в Windows так не будет.
Ну, это с самого начала было понятно — потому что «обратная совместимость». 99% болячек Windows имеют ровно один корень — нельзя ломать то, что когда-то работало, а потому любое неосторожное движение приводит к тоннам боли по устранению последствий.
Если вернуться на 10 комментов назад к изначальной проблеме, то защита линукса строится на том, чтобы пользователь задолбался включать запускаемость
Не совсем так. «Защита линукса» строится на том, что понятия «чтение файла» и «исполнение файла» — два принципиально разных понятия. При этом права доступа в линуксе далеко не идеальны (и очень сильно примитивны/ограничены), и растут из настолько дремучих времен, когда массовое использование компьютеров в бухгалтериях по всему миру еще казалось фантастикой.
По факту, собственно запустить файл на исполнение в линуксе не намного сложнее, чем в винде — скопируйте в «хомяк», поставьте галочку и запустите по правой кнопке мыши. И даже если noexec не стоит, и если права на исполнение файла на флешке вы имеете, просмотр файла будет происходить по дубль-клику, а запуск — по правой кнопке мышки и выбору соответствующего пункта меню. Это к вопросу об авторанах и прочих «самыйЛучшийФильмБезРегистрацииИСмс.avi.exe» — сама концепция на linux'е не взлетит.
а значит, при приходе линукса в массы эту всю фигню быстро автоматизируют
Ну, собственно, если считать андроид линуксом, то в массы он уже вышел, и не автоматизировали. Если не считать — посмотрите на «соседей». Та же винда очень сильно стремится получить широкое использование ровно тех же механизмов распространения софта, что есть у линухи: репозитории (которые в коммерческих платформах упорно вырождаются в магазины приложений).
При поголовной интернетизации, собственно, вся эта запускаемость со съемных носителей стремительно теряет всякий смысл. А окошко «вам опасно запускать этот бинарник» в винде — следствие попыток решения ровно одной проблемы: исполняемость файла определяется его расширением, которое по умолчанию скрыто. Как уже выяснилось, в результате вырабатывается «иммунитет» и «заученная последовательность действий», глаз замыливается, и все забивают. Изначальный посыл «защитить пользователя» размывается, потому что добровольные механизмы защиты не работают, нигде, проверено. Остается назящее окошко, которое всех бесит, никого ни от чего не спасает и единственный способ заставить его как-то работать — это с некоторой периодичностью менять расположение кнопок «дальше», «мне пофиг», «я осознаю всю опасность» и «все равно запустить». Причем менять их надо в произвольном, наименее удобном для пользователя порядке, и надписи тоже менять — только так вы заставите пользователя прочитать, что там написано.
Например, web-инсталлеры хрома, гога или стима представляют собой маленький exe-шник, запускаемый одним кликом, который всё докачивает.
«Однокнопочные» механизмы распространения и так существуют, и они к правам запуска ортогональны. По факту, у вас есть репозитории, у вас есть всяческие докеры и иже с ними, у вас есть flatpak и snap, у вас есть appImage, и это без учета таких вещей, как «разложи файлы по правильным местам» или «собери сам».
Вообще, кстати, тот же flatpak, snap или набор репозиториев — просто какая-то мечта для разработчиков проприетарных ОСей. Собственно, вся муть с блокирующими окошками она для того и делается — чтобы загнать виндовс-разработчиков в Microsoft Store. Т.е. майки сами хотят именно того, чтобы какие-то пользователи случайные файлы с каких-то мутных мест интернетов не запускали. Прямо мечтают обрубить саму возможность такое делать по самые локти, но не могут, «потому что все привыкли именно так». Так и живем.
Суть проблемы именно в «так привыкли». Я пользуюсь
Юзеры либо привыкнут и будут на автомате скачивать файл, ставить +x и запускать правой кнопкой, либо это всё будет автоматизированно в «новом удобном браузере Амиго».
Собственно, все идет к тому, что везде-везде по дубль клику ничего запускаться не будет. А хром, гог или стим — они и сейчас ставятся на линуху, правда, справедливости ради, с некоторыми приседаниями, хоть и не сильно большими.
необходимость выполнения отдельно chmod 0644 по файлам в рамках иерархии и 0755 — для папок — это от сильно большой продуманности.
У NTFS как раз есть разделение между чтением и выполнением:
по части разрешений IMHO NTFS обходит штатный rwx на нес-ко голов. Впрочем, POSIX ACL тоже недалеко ушел от rwx — просто увеличивает число принципалов, к-рым можно назначить права через setfacl.
Это не считая того, что UID'ы пользователей на разных ПК у Linux могут дублироваться — и кто получит права на запуск файлов подключённого диска или распакованного архива поди догадайся.
У NTFS как раз есть разделение между чтением и выполнением:
а можно детальнее:
по части разрешений IMHO NTFS обходит штатный rwx на нес-ко голов. Впрочем, POSIX ACL тоже недалеко ушел от rwx — просто увеличивает число принципалов, к-рым можно назначить права через setfacl.
Это не считая того, что UID'ы пользователей на разных ПК у Linux могут дублироваться — и кто получит права на запуск файлов подключённого диска или распакованного архива поди догадайся.
UFO just landed and posted this here
по части разрешений IMHO NTFS обходит штатный rwx на нес-ко голов.
Собственно, этого я и не отрицал. Юниксовый RWX — это штука, которая рождалась группой математиков для математиков в те далекие времена, когда компьютеры были большими, память — маленькой, а массовое применение компьютеров в реальных многопользовательских системах было чем-то из разряда фантастики. И штука эта, как и все, изобретенное талантливыми математиками, непротиворечива, проста до примитивизма, содержит долю тонкого математического юмора, а также слабо применима в условиях дикой природы и как есть. На ролевую модель среднестатистического бизнеса оно ложится слабо, но работает отлично в философии «собор и базар». Отсюда очевидно, что для бизнес-задач (не технических, а тех, которые определяются именно запросами бизнеса, читай административных) NTFS-модель уделывает юникс-права, как г-дь черепаху, она ровно для этого и рождалась. В ней есть иерархическое наследование, в ней есть возможность назначать отдельные наборы прав для множества отдельных групп и даже отдельных пользователей, не являющихся при этом владельцем. Но все это увеличивает общую комплексность управления всем этим хозяйством.
На фоне этого, невзирая на общее неоспоримое превосходство NTFS-прав над Unix-моделью… Вот в этом месте стоит упомянуть, что любая комбиная rwx, за исключением конкретного частного случая x+r-, т.е. «исполнение без права чтения», может быть напрямую оттранслирована в ntfs-права, а в обратную сторону не работает, т.е. ntfs в общем случае шире. Нужна ли вам возможность дать пользователю права выполнить файл без возможности просмотреть содержимое или скопировать файл куда-либо — это вопрос конкретно ваших задач. Ну, в контексте системных файлов, стоит признать, достаточно полезно, имхо. В целом — не знаю, насколько «стоит свеч» отказа от ntfs-привилегий.
Ну так вот, собственно, на фоне этого, невзирая на общее неоспоримое превосходство NTFS-прав над Unix-моделью (в контексте гранулярности набора прав), у rwx-модели есть таки ровно пара преимуществ (имхо, может больше), разной степени критичности и право выбора остается за вами.
Первое — это отсутствие механизма наследования (звучит странно, но наследование — это такая штука, которая умеет играть как в плюс, так и в минус). Собственно, то, что вы в целом можете делать с файлом определяется только и исключительно правами доступа на сам файл, вне зависимости от его выше/ниже/рядомлежащих соседей. В процессе отладки и рабора полетов — очень и очень полезная штука.
Ну и вторая вещь, работающая ровно в контексте окружающей системы (являющаяся, по моему мнению, таки киллер-фичей) — это то, как работает «x» в rwx-комбинации. Его поведение серьезно отличается от «Read&execute» ntfs-прав. NTFS-права на исполнение указывают исключительно разрешение конкретному адресату прав на исполнение файла, rwx-овый x означает, кроме того, собственно признак исполнимости файла.
В Windows-системах «исполнимость» файлов как таковая определяется его расширением. При этом поверх этих же расширений работает механизм файловых ассоциаций, что размывает понятия «просмотр» и «исполнение», и делает возможными атаки вида «СамыйЛучшийФильм.avi.exe», а также дает возможность поломать к хренам весь юзерспейс выставлением ассоциации на exe, com, bat и т.д. файлы (к слову, так и не могу понять, почему файловые ассоциации отрабатываются раньше, чем контроль исполнимости — загадка и очевидный баг, имхо).
В nix-системах «исполнимость» файла определяется правами на него и не существует в отрыве от ФС. Собственно, не уверен, что сложить признак исполнимости файла именно в ФС — прямо лучшая из возможных идей, однако само разделение механизмов исполнения и просмотра — безусловное благо, а бонусом от ФС-пришитости мы получаем возможность контроля x-атрибута средствами монтирования файловых систем, что в ряде случаев позволяет сделать систему в целом более безопасной.
Из элементарных примеров — возьмем флешку под fat32, который никаких прав доступа не хранит, т.к. просто не обучен. В контексте Windows-систем ограничений на доступ к файлам нет, т.е. «на этой флешке все можно», а исполнимость exe-шника, лежащего на флешке, определяется его расширением, т.е. дубль-клик по exe-файлу, лежащему на флешке приводит к его запуску. И даже если вы групповыми политиками запретили запуск с флешки, этот exe-шник все еще можно скопировать в хомяк и запустить оттуда.
В Linux-системах минимальным необходимым требованием для запуска файла является наличие x-права на уровне ФС. В fat32 прав никаких нет, т.к. и x там тоже отсутствует. В процессе копирования в хомяк никаких прав на исполнение вы тоже не получите. Т.е. этот вектор атаки отстутсвует.
Если же вы монтируете файловую систему, хранящую права доступа, бонусом от «прибитости исполняемости файла к правам ФС» вы получаете возможность подмонтировать ФС с опцией noexec, которая игнорирует все наличествующие в правах x-ы и делает вид, что на файловой системе их нет.
Собственно, вот об этом я и говорил. Ни в коем случае не утверждал, что rwx-как-таковая лучше ntfs-прав.
Это не считая того, что UID'ы пользователей на разных ПК у Linux могут дублироваться — и кто получит права на запуск файлов подключённого диска или распакованного архива поди догадайся.
Я вам больше скажу, они не могут, они будут дублироваться с очень высокой вероятностью. Ну, хотя бы, потому, что они вообще не UID'ы, а просто числа, получаемые инкрементом в порядке создания пользователей.
Однако, если честно, не совсем понял суть проблемы. Вы таки сетуете на то, что те, кому не надо, могут получить доступ, или таки на то, что те, кому надо, не получат? Собственно, в ограничении доступа «злоумышленников» или «случайных злоумышлятелей» уникальные UID'ы вам дадут примерно ничего, т.к. эти UID'ы — это просто последовательности байт, к которым привязаны наборы ntfs-прав. При любом подходе права на «местных» пользователей можно и нужно выставлять заново. Если нужна защита — шифруйте диск, остальное не работает. Не вижу, каким образом уникальные UID'ы кого-то от чего-то защитят.
Если же вы сетуете на то, что кто-то чего-то недополучит — тут уж от опций монтирования зависит, а при правильной настройке ntfs-умолчаний, по умолчанию никто не получит ничего.
В общем и целом, сценария «вытыкания» ФС из одного компьютера и «втыкания» в другой я вижу два. Один — явно выраженный съемный носитель, т.е. инструмент для переноса данных из точки A в точку B — не вижу ни одного действительно оправданного варианта как для разграничения доступа пользователей конкуррентной среды к содержимому ФС (права должен получать, очевидно, тот, кто флешку воткнул), так и для выдачи каких-либо прав на исполнение содержимого (запускать софту с флешки — зло и извращение).
Второй вариант — подцепление ФС с содержимым «на постоянку». Тут либо вы просто складываете данные «как есть», цепляете к целевой машине, а уже «на месте» настраиваете права — это нормальная практика. Либо вы складываете на ФС данные, настраиваете права так, как это должно выглядеть на целевой машине (к слову, с числовыми айдишниками это сильно проще), и уже готовую настроенную ФС подключаете на место постоянного проживания. Это тоже нормально.
Все остальные варианты, честно говоря, мне лично кажутся странными. И ntfs-права, и rwx-троица, собственно, проектировались с прицелом на распределение прав внутри одной существующей функционирующей системы. Перенос ФС на другую машину «как есть» работает одинаково плохо для обоих наборов прав — они не на то рассчитаны были.
UFO just landed and posted this here
А что насчет программ, которые устанавливаются в
Кстати, а bat/ps файлы считаются исполнимыми? А другие скрипты (python, например)? А то так можно и доwhitelistallowlist дойти, в котором только calc.exe и notepad.exe будут (естественно, с полными путями и, на всякий случай, хешами этих файлов).
Я понимаю, что в корпорациях админ может заблокировать всё, кроме реально необходимого минимума. Но что делать «обычным» пользователям на домашних компьютерах?
PS. Прошу прощения за легкий троллинг.
%LOCALAPPDATA%? Или тех, которые сам компилируешь? Я понимаю, что скорее всего Вы предложите запретить и это, но в том же Linux такое не запрещено и на безопасность никто не жалуется.Кстати, а bat/ps файлы считаются исполнимыми? А другие скрипты (python, например)? А то так можно и до
Я понимаю, что в корпорациях админ может заблокировать всё, кроме реально необходимого минимума. Но что делать «обычным» пользователям на домашних компьютерах?
PS. Прошу прощения за легкий троллинг.
UFO just landed and posted this here
Очевидно, они нарушают модель безопасности ядра NT и должны быть изменены.
Что-то вообще не очевидно. Оно ровно так работает по умолчанию, а это может значить ровно один из трех вариантов:
1. Нарушают они лично ваше представление о «модели безопасности ядра NT», и оное представление отличается от суровой реальности.
2. Реальная модель безопасности ядра NT не используется никем, включая разработчиков этого самого ядра.
3. Модель безопасности ядра NT имеет очень слабую забагованную реализацию, которая нарушается настолько просто, что аж дефолтные настройки Windows ее нарушают.
Ну, тут уж сами определитесь, какой вариант вам кажется более верным. Собственно, начните с отделения «модели безопасности ядра NT», как инструмента настройки ролей/прав доступа (которая таки вполне сносно работает, готов даже дать соответствующие показания), от политик безопасности, определенных для конкретной организации/машины/в вашей голове. Вот собственно настройки эти самые — это личное дело каждого (администратора), и я, в целом, на вашей стороне и всецело поддерживаю запрет исполнения файлов откуда-либо кроме Program Files. Но реальность показывает, что в настройках по умолчанию все сделано не так, и даже специальная переменная окружения %LOCALAPPDATA% заведена для покрытия этого случая. Если ее кто-то завел, значит, это кому-нибудь нужно, что наталкивает нас на мысль, что существует еще одно возможное объяснение «Парадоксу sumanai» (ситуации, когда дефолтное поведение системы противоречит модели безопасности ядра, поверх которого эта система построена) — возможно, разработчики просто хотят зла пользователям и сделали это специально, чтобы простые парни, приходя с завода с мыслью посмотреть на компьютере сериальчик или поиграть в игрушку под пивко, вместо этого страдали…
Ну, это так, на правах предположения, просто шальная мысль.
Разработчикам программ следует наконец прочитать гайды и ставить программы куда нужно.
Простите, еще раз не удержусь и сделаю пару замечаний по сути фразы:
1. Есть мнение, что разработчики того же Хрома из того же Гугла, таки гайды читали, и почему-то решили положить на них болт, и у них почему-то получилось. Похоже на то, что они «взломали систему»! Значит ли это, что у Гугла программисты круче, чем в Микрософте?
2. Разработчикам системы также стоит, видимо, прочитать собственноручно написанные гайды, и предпринять какие-то действия, чтобы дефолтные настройки системы им следовали. Да и ребятам из соседних отделов дать почитать, а то, по всей видимости, они эти самые гайды хранят под 7 замками и продуктовым разработчикам из своей же конторы читать не дают! Например, разработчикам Офиса почитать не дали — он отлично в хомяк встает, как влитой. За «шах и мат» считается?)))
Прошу прощения за серьёзный ответ на троллинг.
Сорян за серьезную реакцию с элементами троллинга в ответ на серьезный ответ на несерьезный троллинг с вкраплениями весьма ценных мыслей, последовавший за серьезными рассуждениями из предыдущей полусерьезной беседы по сути и не очень.
Добавим чутка серьезных мыслей: в реальной дикой природе данное поведение (все из Program Files), к сожалению, малодостижимо, а также несет в себе некоторое количество неконструктива и даже негативных последствий. Например, посадить человека без админских прав просто попрограммировать под своей личной пользовательской учеткой — становится невыполнимой задачей. «Кодить на нативных компилированных языках» станет привилегией админов локалхоста — тоже такое себе.
1. Есть мнение, что разработчики того же Хрома из того же Гугла, таки гайды читали, и почему-то решили положить на них болт, и у них почему-то получилось. Похоже на то, что они «взломали систему»! Значит ли это, что у Гугла программисты круче, чем в Микрософте?
2. Разработчикам системы также стоит, видимо, прочитать собственноручно написанные гайды, и предпринять какие-то действия, чтобы дефолтные настройки системы им следовали. Да и ребятам из соседних отделов дать почитать, а то, по всей видимости, они эти самые гайды хранят под 7 замками и продуктовым разработчикам из своей же конторы читать не дают! Например, разработчикам Офиса почитать не дали — он отлично в хомяк встает, как влитой. За «шах и мат» считается?)))
Это традиционная специфика Майкрософт как очень большой компании, вынужденной поддерживать кучу легаси при помощи самых разных костылей. Анекдот «У нас есть N стандартов, кошмар! Надо придумать один новый, который заменит их все. Через некоторое время: у нас есть N+1 стандарт» — это абсолютно про них.
Это традиционная специфика Майкрософт как очень большой компании, вынужденной поддерживать кучу легаси при помощи самых разных костылей.
В целом, я это понимаю. Однако «вынужденной поддерживать кучу легаси» звучит несколько странно на фоне того, что в этой куче находится, например, Microsoft Office 365, который by design свежий, и при этом разрабатывается такими же ребятами в соседней комнате той же организации. Произносить выспренные фразы «все эти говноразработчики должны наконец прочитать рекомендации» стоит ровно с момента, когда «элитные специалисты по разработке софта компании Майкрософт» с ними ознакомятся.
Если уж в пределах одной компании этим «рекомендациям» не следуют, странно «на зеркало пенять, коли рожа крива». Покажите уже, наконец, на примере своего софта, каким должен быть правильный софт. Чей, если не майковский, софт считать эталоном, образцом для подражания в разработке под Windows?
Других эталонов не имеем, и до тех пор, пока эти эталоны вполне себе устанавливаются в хомяк, тыкать пальцем в окружающих с пафосными выкриками «из хомяка запускаться нельзя», «вы тут нам это, нарушать прекратите, вы ломаете мою безопасность» и «прочитайте рекомендации, которые мы для вас пишем, там написано, что так нельзя» — какая-то фантасмагория.
UFO just landed and posted this here
Замечу, что данной фразы я не писал.
Ну да, вы писали вот эту: «Разработчикам программ следует наконец прочитать гайды и ставить программы куда нужно.»
Мне кажется, в вашей коннотации «разработчик, все еще не прочитавший гайды» имеет ярко выраженную окраску «не очень хороший разработчик», не?
Зачем свой.
Я имел в виду «свой» в значении «микрософтовский». Мне лично кажется странным, когда солидная контора выпускает рекоммендации для софта, которым не следует софт, написанный этой конторой. Microsoft Office, Visual Studio Code, тысячи их — допускают установку в «хомяк». Т.е. майкрософт считает запуск из домашней папки пользователя штатным механизмом Windows. Не вижу ни единой причины разработчикам за пределами Microsoft придерживаться какой-то иной точки зрения.
Просто 90% софта работает правильно и не отсвечивает.
У вас какие-то странные 90%. Даже если отсечь все «одноразовые», «самодельные» и «узкоспециализированные» вещи и сконцентрироваться на самом широкораспространенном и популярном софте — картина сильно отличается от представленной вами. Топ браузеров под Windows: Chrome, Firefox, Edge. Из этих трех в хомяк не встает только Edge, остальные написаны людьми, «все еще не удосужившимися прочесть гайды». Adobe Photoshop, Corel DRAW и компания — все встают в хомяк как влитые. Тоже, очевидно, ленивыми программистами написаны. Любой мессенджер (а их десятки), за исключением скайпа отлично встает в хомяк. IDEшки (в значении Integrated Development Environment) — в хомяк встают все, кроме Visual Studio. Казалось бы, «Ага!!! Вот, посмотрите, микрософтовская не встает! Это остальные — рукожопы». Ан нет, Visual Studio Code от того же микрософта отлично в хомяк встает.
Так что давайте уж определимся таки: запуск приложений извне ProgramFiles — штатный механизм Windows, никоим образом «модели безопасности NT» не противоречащий. В конце концов в винде пользователь напрямую работает с концепцией дисков/томов. В Windows не предусмотрено абстрагирующей надстройки в виде FHS (иерархии файловой системы). В свете этого сама идея «запуск приложений только из Program Files» кажется утопичной и нереализуемой хотя бы из соображений доступного дискового пространства.
UFO just landed and posted this here
Допускает. Но у меня он стоит где нужно. Не использую офис, но считаю, что у него тоже есть такая опция.
Ну, собственно, если само наличие «опции» установки в Program Files переводит софтину из разряда «написано чуваками, которые не читали рекомендации» в разряд «нормальный софт», искренне не понимаю, в чем смысл вашего высказывания «им пора бы уже прочитать рекоммендации». Любая софтина имеет «опцию установки в Program Files», вот прям любая. Собственно, «установка в Program Files» от «установки в хомяк» отличается исключительно местоположением исполняемого файла. И даже склонность программы писать в папку, в которой она лежит, очень просто лечится установкой workdir. Короче, так и непонятно, зачем читать рекоммендации.
Вы не правы. Firefox встаёт куда нужно
И все таки, подскажите, откуда взялось понятие «куда нужно». Где конкретно указано, куда нужно складывать бинарники?
про хром не уверен, но у него должна быть версия в msi, которая встаёт куда нужно.
Зачем? Если под «куда нужно» понимать Program Files, то обычный инсталлятор хрома отлично умеет туда ставить, с единственным нюансом — при наличии прав администратора. Собственно, он поддерживает 2 штатных варианта установки: только для себя — в хомяк, и для всех — в Program Files.
У меня телеграм, который из стора, и стоит в Program Files\WindowsApps. Что я делаю не так?
Я вам подскажу: любое приложение из стора будет стоять в Program Files/WindowsApps. И это, собственно, не хорошо и не плохо, это просто данность, у которой есть свои минусы. А в целом — просто поставьте не из полумертвого стора, и сможете выбирать, куда ставить.
Это штатный механизм, спору нет. Наследие Legacy. Но модели он противоречит. Иначе в принципе нельзя обеспечить безопасность ОС.
Вот это поток сознания. Итак, по вашим же словам:
1. Это штатный механизм.
2. Штатный механизм противоречит модели безопасности.
3. Это единственный способ обеспечить безопасность.
Вот реально??? Единственный способ обеспечить безопасность системы — это чтобы штатный механизм этой системы противоречил модели безопасности этой самой системы? Вы сами понимаете, что вы несете? Вы прямо заявляете, что единственный способ достижения безопасности — это забить на модель безопасности…
Или вы имеете в виду, что есть модель безопасности, которая — единственный способ обеспечения безопасности, но штатный механизм ей противоречит, и поэтому обеспечить безопасность нельзя, и поэтому вся эта муть просто не работает, и всех это устраивает?
Ну, тоже такое себе. Подскажите какой-то другой вариант толкования ваших слов. Я дважды попытался, ересь какая-то выходит.
UFO just landed and posted this here
Нет. Сейчас пошла мода на установку без вопросов.
То, что оно молча ставится, куда придумает — это я и так знаю. Но по поводу опции — покажите мне софтину, которую я в Program Files поставить не смогу.
Не представляю как вы это вывели.
Внимательно, вдумчиво прочтите вот это:
«Это штатный механизм, спору нет. Наследие Legacy. Но модели он противоречит. Иначе в принципе нельзя обеспечить безопасность ОС.»
UFO just landed and posted this here
PostMan? Он вроде как раз без вопросов в профиль залетел.
Ну, собственно, берем exe-шник инсталлятора Postman. Это самораспаковывающийся архив, с удовольствием взглянул на «внутренности». В общем и целом, внутри иконка, чуть мишуры и NuGet-пакет.
Папка установки регулируется, если верить документации (под рукой винды нет, вечером перепроверю), тут: %ProgramFiles(x86)%\NuGet\Config. Конфиг уровня пользователя лежит здесь: %appdata%\NuGet\NuGet.Config. Вот там можно выбрать, куда ставить, включая ProgramFiles.
«Умолчания» при этом такие: %userprofile%\.nuget\packages. Вот сюда оно устанавливает пакеты. Кхм, и это — штатный рекомендуемый пакетный менеджер от MS. И эти люди
Ну, в общем, челлендж, вроде выполнен? Порядок действий такой: правим настройки NuGet, чтобы ставил внутрь ProgramFiles, устанавливаем Postman — встает туда, куда мы определили. Я справился?
Я пишу о том, что чтобы обеспечить безопасность ОС, нужно игнорировать штатную возможность запускать софт откуда попало.
Ну, во первых, игнорировать — это «взять со всех пользователей обещание никогда-никогда ей не пользоваться и вообще делать вид, что ее нет». Вы же понимаете, что это работать не будет? Т.е. ее надо блокировать.
Что мы получаем на выходе? Штатная модель безопасности блокирует штатную возможность… Вы это, либо крестик снимите, либо рясу в трусы не заправляйте! Не должна система безопасности блокировать штатные (еще раз, по буквам, ш т а т н ы е) возможности! Иначе какие они, к чертям, штатные?
UFO just landed and posted this here
Кстати, да. Нажатие ENTER в Midnight Commander тупо запускает исполняемый файл. А нам кто-то 500 постов подряд доказывал, что так просто, тупо по клику, ничего не запускается.
Нажатие ENTER в Midnight Commander тупо запускает исполняемый файл. А нам кто-то 500 постов подряд доказывал, что так просто, тупо по клику, ничего не запускается.
Давно нажатие ENTER в mc, с предварительным запуском этого самого mc стало «тупо кликом»?
И, к слову, первое, что я доказывал — запуск приложения на исполнение и открытие файла дефолтным просмотрщиком — два явным образом раздельных действия в линуксе.
UFO just landed and posted this here
Давно нажатие ENTER в mc, с предварительным запуском этого самого mc стало «тупо кликом»?Т.е. mc написан не по канонам?
А так, чем mc хуже любого другого шелла?
Одно время, я упарывался на винде и вместо explorer.exe прописывал shell — far.exe, мне так было намного удобнее работать
Т.е. mc написан не по канонам?
Не, я скорее про то, что mc в список софты, широко используемой неподготовленным пользователем, по моим понятиям, например, никак не входит.
Так когда mc появился, он был как нортон командер — любимым шеллом обычного пользователя. То есть, раньше в линуксе считалось нормальным выполнять по ENTER, а теперь времена изменились?
Так когда mc появился, он был как нортон командер — любимым шеллом обычного пользователя.
Что-то мне кажется, что в 1994 году понятие «обычный пользователь» разительно отличалось от сегодняшнего. С трудом представляю себе свою жену, собирающую из исходников ядро linux, чтобы на нем запустить сборку mc…
Ну и, собственно, кроме как «выполнить» файл на тот момент вариантов и не было. Какбэ, механизма файловых ассоциаций еще не существовало, фильмы на компьютерах еще не смотрели, с качеством музыки были явные проблемы, а открытие файла на просмотр делалось явно по F3, не по enter'у.
Как запустите, тогда и поговорим.
Вснепременно сообщу о результатах, нотариально заверенные скрины приложу.
Что вам не нравится? Вы очень много придираетесь к словам, буквам и определениям. Да, одна штатная возможность блокирует другую, почему бы и нет. Там же я могу заблочить запуск хоть штатного калькулятора, если мне будет нужно.
Заблокированная политиками безопасности возможность перестает быть штатной же. Нельзя заблокировать возможность и продолжать называть ее штатной. Да, я люблю четкие определения, вот такой я плохой.
Также как нельзя размахивать «рекоммендациями, которые всенепременно обязан прочесть каждый разработчик, прежде, чем начать программировать», не указав ссылки на эту рекоммендацию. Нельзя утверждать, что запуск программ извне ProgramFiles противоречит «модели безопасности NT», не предоставив ссылки на оную модель и упорно продолжая игнорировать тот факт, что микрософтовские продукты продолжают устанавливаться в хомяк и это нормальная практика с точки зрения микрософта (тем более, что относительно свежие инструменты майков вроде того же NuGet ведут себя именно так).
Нельзя утверждать о реальном существовании модели безопасности и присущих ей признаках в условиях, когда на эту модель все болт кладут, включая разработчиков этой самой «модели безопасности».
Кстати, я сейчас на Linux, и я запускаю robo3t дабл кликом по «экзешнику» по пути /home/%username%/robo3t-1.3.1-linux-x86_64-7419c406/bin. Шах и мат?
Прикольно, проверил. Где-то я подотстал от «юзабилити» в текущей моде. Не понял, где тут шах и где мат, однако. Тупо IDE-специфичное поведение, поведение одного из доступных IDE.
UFO just landed and posted this here
В смысле? Если я не пользуюсь штатной аудиосистемой, то она перестанет быть штатной? Хорошо, для фанатов строгости могу её отключить. Всё, теперь она точно-точно не штатная?
Ну, собственно, если вы ей просто не пользуетесь — штатная. Если она не работает — то она либо поломана (если так не задумано), либо уже не штатная (если так и надо).
Сорян, я не профессиональный разработчик под Windows, и не знаю от корки до корки всю её документацию.
Т.е. рекомендации, касающиеся вснепременнейшей установки программ в ProgramFiles, а также содержащие ласковое порицание всех, кто устанавливает что-то в хомяк, вы не видели? И спецификацию «модели безопасности NT», в которой явно написано, что из-за пределов ProgramFiles ничего запускать нельзя, тоже не читали? Может быть, потому, что обоих документов не существует в природе, а «разработчикам пора уже что-нибудь прочитать» — просто пафос, ничем не обоснованный?
Проверяли то где? Я в Cinnamon, вы наверняка в другой оболочке. Ой, уже не одного.
Написал же, в третьегноме. При этом во второгноме как не работало, так и не работает.
UFO just landed and posted this here
Может и видел
Ну, в общем, давайте сойдемся во мнении, что, может быть, и видели, но оно давно уже устарело. В определенный момент майки действительно достаточно назойливо пытались продвигать ProgramFiles как единственное место для установки программ (забыли только в /usr/bin переименовать, тогда бы точно взлетело), и даже была где-то когда-то дефолтная политика с запретом на исполнение в хомяке. Только времена эти ушли, микрософт сдался, и вышеупомянутые рекомендации, равно как и политики, канули в Лету. Ставить в хомяк совершенно не порицается на данный момент, в принципе, даже понятно, почему.
Увы, помню только сторонний документ, где чётко расписано, что, куда, зачем и почему.
Ну, старенький документ, очень старенький. Стоит признать, что с тех далеких пор (2009 год) майки сильно подтянулись, стали лучше. И даже в документе я прямого упоминания «ставить только в Program Files» не нашел.
Собственно, главная проблема Program Files в моем понимании — как раз и состоит из комбинации «путь-от-диска» + «диск не бесконечен». Ну, те. ProgramFiles таки рождены ровно в пределах системного диска. Оно и хорошо бы, например, если место поджимает, подмонтировать туда же еще какой диск — ан нет, это очень плохо работает на винде.
Окей, уже две среды нарушают установленное вами поведение, не считая mc. Сколько примеров вам ещё нужно, чтобы доказать, что Linux к нынешнему времени не отличается от Windows в плане «Скачал архив с программой, распаковал и запустил»?
Ну ладно-ладно. Один всего нюанс остался — права доступа. Tar-енные архивы rwx сохраняют, а те же зазипованные и зараренные — нет. Ну и, собственно, с fat32 раздела гарантированно не запустите. И с флешки — тоже сомнительно (хотя дефолты могут плавать). А в остальном, как бы я ни расстроился от этого, да, бубль-клик теперь общая проблема. Так и хотелось сказать «А из-за кого? И кто в этом виноват...» Но ладно, не буду.
UFO just landed and posted this here
Да да, не пугать пользователя UAC.
Ну да, и «модель безопасности NT» именно об этом и говорит: «не пугать пользователя UAC». Остального не говорит.
система будет защищена от вирусного поражения и всяких там шифровальщиков практически на 100%.
Ай, неправда ваша! Совершенно недостижимо ведь!
Плохо читали. Очевидно, если настроить систему по протоколу, то ставить куда либо ещё не имеет смысла, так как оттуда будет запрещён запуск.
Совершенно неочевидно, как то, что не имеет смысла, так и то, что именно оттуда будет запрещен запуск. Непонятно, почему вы не можете выделить какую-то еще одну папку для складывания программ, например. Могу даже обосновать, зачем: предположим, у вас в конторе есть куча самописного софта, который нужно куда-то деплоить в соответствии с внутренними политиками. Очевидно же, с учетом механизмов деплоя, что собственный софт, регулирующийся собственными политиками с самописным деплоем, есть некоторый смысл хранить отдельно — хотя бы для упрощения управления деплоем и заради отсутствия необходимости согласовывать свои политики с теми системными политиками, которые регулируют Program Files. Да элементарно, при обновлении системы вполне себе можно на грабли с изменением политик налететь. Просто сложите внутренние программы в отдельную папочку — и будет всем счастье.
Вот не знаю, куда монтировать? В Program Files? Или его 32 битный аналог?
Это, очевидно, от битности софты зависит. Оно бы хорошо симлинками вообще разрулить — но с исполняемым софтом симлинки ведут себя из рук вон…
Да и в Linux я например не стал бить диск, ибо чёрт его знает, где мне место понадобится. Сложно это.
Порядок — это всегда сложно…
Как по мне, так самое простое решение — купить диск с запасом.
Так точно: просто купи!
Ну так по умолчанию запуск под виндой разрешён.
Это плохо(((
UFO just landed and posted this here
Забавно, откуда вы это вывели?
Ну, например, оттуда, что мне тут неоднократно указывали на «модель безопасности NT, которая запрещает запуск извне Program Files». При этом спецификацию так и не привели, а само утверждение очевидно абсурдно, хотя бы по причине наличия устоявшейся практики, явно ему противоречащей. Поэтому я и подумал, что если хочется какую-то свою фантазию подкрепить якобы существующим документом для пущей важности и убедительности, нужно использовать фразу «модель безопасности NT». Нет?
Понимаете, я не против формулировки «запуск извне Program Files противоречит разумным политикам безопасности» и даже «запуск извне Program Files противоречит здравому смыслу». Однако подмена явно выраженной коннотации «в моих, вроде бы, верных рассуждениях о том, как это должно работать» на давление авторитетом вроде «противоречит модели безопасности NT» — ну, такой себе прием, с душком.
Сарказм это хорошо, когда он здоровый.
К сожалению, это не сарказм. 100%-ная безопасность недостижима.
Выделяйте, без проблем. Но это будет уже нестандартная конфигурация, вам её придётся настраивать вручную. И да, права не забудьте.
Ну вот с этим выделением папки как таковой проблем нет на обеих системах. А вот «тиражировать» это изменение на Windows-системах несколько геморройней. Вся суть удобства линуксовой FHS в неизменности путей на разных физических системах. Т.е. «где что лежит физически» регулируется на уровне ядро/ФС, и по этому причине хорошо работает. На прикладном уровне этот пласт «приседаний» вида «определи, на каком диске оно лежит» отсутствует. Он не в принципе отсутствует, а на прикладном уровне отсутствует, т.к. расположен ниже него и надежно от оного абстрагирован.
У меня есть дополнительный жёсткий диск. Куда мне его монтировать?
Ну, собственно, на виндовсе — некуда и незачем. А симлинки так себе работают.
UFO just landed and posted this here
В чём тут отличие? У меня есть два диска и две системы, одна Windows, другая Linux. В чём отличие добавления нового в этих системах? И там и там мне придётся решать вопросы, куда диск будет размещён, какие файлы там будут лежать, как их туда перемещать.
Отличие проявляется в том, на каком уровне вы эти проблемы решаете. На единичной машине разницы да — никакой. А теперь представьте парк из 50 машин. В линухе проблема решается исключительно системным администратором, который распределяет, как использовать ресурсы, доступные на машине. Весь уровень приложения от этих деталей абстрагирован, на уровне приложения никакой специфики уровня машины не существует. Если приложение хочет «насрать в хомяк», оно совершенно законно это делает по ссылке ~/куда/срать или, если предпочитает полные пути, /home/%username%/куда/срать — и это гарантировано одно и то же место, но совершенно не гарантировано, что один и тот же диск. Т.е. абсолютный путь в linux гарантирует, что приложение попадет куда надо, вот никак не промахнется, т.к. иерархия одна.
В винде абсолютный путь гарантирует… ничего. Вы можете оказаться как на соседнем диске, так и в другой папке. Или не оказаться — да хрен его знает. Поэтому фактически абсолютный путь не факт, что абсолютный, относительный — он и в Африке относительный, и на выходе все дружно приседают со специальным переменными окружения и настройками в реестре. При этом сама корректная работа с симлинками, например, не гарантируется, т.к. приложение должно уметь ходить по симлинкам. Реализация такая: симлинк — это файл с расширением .lnk. Т.е. существование рядом файла «МояОченьНужнаяПапка.lnk» и непосредственно папки «МояОченьНужнаяПапка» — ничему не противоречит, совпадения имен нет (к слову, еще одно странное решение на базе все того же расширения файла, которое теперь вылазит боком). Если приложение работает поверх устаревшего API, не умеющего в симлинки, оно просто может взять и создать недостающую папку рядом с симлинком, и просто все сломать.
Поэтому что-то сколько-нибудь критичное (Program Files, ProgramData) переносить на отдельный диск сам микрософт совершенно не рекомендует. Т.е. «оно, как бы, и можно, но не рекомендуется». И готового решения этой проблемы на уровне приложения нет, потому что это не проблема уровня приложения, а утекшая абстракция ФС.
А с Linux, а с Linux то как?
А с Linux, например, в /usr/local? Ну или пофигу куда, т.к. сама болячка «необходимость содержания отдельных ProgramFiles и ProgramFiles(86)» проистекает ровно из привычки «все свое ношу с собой», поголовного вынужденного пользования относительными путями и неумения при линковке определить, какой битности библиотеку линковать.
Ну или пофигу куда, т.к. сама болячка «необходимость содержания отдельных ProgramFiles и ProgramFiles(86)» проистекает ровно из привычки «все свое ношу с собой», поголовного вынужденного пользования относительными путями и неумения при линковке определить, какой битности библиотеку линковать.вы себе специально грабли раскладываете?
/lib
/lib64UFO just landed and posted this here
Сами бинарники-то в /bin, все, и 32, и 64-битные…
Виндовый подход — положить бинарь и заставить его по относительным путям искать линкуемую библиотеку рядом с собой. Поэтому и выходит, что абы куда бинарь не положишь, ну или положишь, но только со всеми зависимостями.
Виндовый подход — положить бинарь и заставить его по относительным путям искать линкуемую библиотеку рядом с собой. Поэтому и выходит, что абы куда бинарь не положишь, ну или положишь, но только со всеми зависимостями.
Виндовый подход — положить бинарь и заставить его по относительным путям искать линкуемую библиотеку рядом с собой. Поэтому и выходит, что абы куда бинарь не положишь, ну или положишь, но только со всеми зависимостями.я вот сперва пытался понять вашу претензию на разделение %ProgramFiles (x86)% & %ProgramFiles% — для чего привел вам пример такого же разделения библиотек в Linux — хотя и там, и там понятно, что хранить что исполняемые файлы, что библиотеки можно где угодно, просто это некие well-known пути, к-рые использовать проще, чем сопровождать каждую программу отдельной записью в PATH.
Но вот это ваше замечание меня совсем удивило. Поиск библиотек вполне можно выполнять по абсолютным путям в Windows (тот самый %ProgramFiles% либо прописанный в ветке реестра программы), по относительным (если есть такое желание разработчика программы) и по well-known путям (перечисленным в PATH).
Какой иной вариант, кроме статической линковки, вы можете предложить? И, самое забавное, как, кроме сборки каждой программы на месте, вы можете обеспечить эту статическую линковку?
UFO just landed and posted this here
UFO just landed and posted this here
Не знаком с разработкой нативного софта, но мне кажется, что для всяких отладчиков так и так нужны админские праваНе нужны. Родительский процесс (IDE) имеет все права над порождённым (отлаживаемое приложение).
Большая часть разработчиков вполне себе следует рекомендациям Microsoft. У них есть инстралятор, который просит права админа, устанавливает программу куда нужно, и впоследствии её можно без проблем запускать от пользователя, так как все настройки пишутся в каталог пользователя.
БОльшая часть разработчиков вполне себе обходится без инсталляторов в принципе — «инфа соточка».
Эм, эта переменная указывает на каталог для хранения локальных файлов программ, которые не обязательны для их работы, например, кешей браузера. Этот каталог не перемещается между компьютерами в домене, для того и был создан. Как он относится к запуску программ из любых каталогов?
Исполнение программ из этого каталога не запрещено по умолчанию. Собственно, как из запуск приложений из кеша скачиваний браузера, например. Лютая дыра в безопасности, имхо.
Всё так и есть. Очевидные причины этому — UAC пугает пользователей, а так как на масштабах хрома даже 0,5% уникумов это солидная пользовательская база, то было решено не пугать их и ставить в хомяк.
Вы забыли еще вариант «админских прав нету, а хромчик очень хочется».
Как уже заметили ниже проблема легаси. Я вот вполне себе сижу с такими настройками (и хромом не пользуюсь), но на масштабах майкрософта даже 0,1% сломанного По превращается в дикий вой всего интернета. Поэтому гайки затягивают постепенно.
Вот, собственно, и я считаю, что основная проблема микрософт — легаси и, соответственно, цена исправления ошибочных решений. С одной стороны, та же система прав NTFS — вещь сама по себе хорошая, достаточно стройная, хоть и не лишенная недостатков. С другой стороны, объединение явного запуска файла и открытия этого файла другим приложением в один «дубль-клик» было стратегической ошибкой, исправить которую на данный момент я даже не представляю как. Так же, как и сокрытие расширения файлов по умолчанию, или политика монтирования дисков, а также очень позднее появление концепции «домашней папки пользователя» как таковой. Все это вкупе делает «рекомендации для разработчиков» полнейшей профанацией, т.к. все отлично понимают, что майкрософт топает ногами, и точно так же будет топать еще 10 лет спустя, потому что «куда они денутся, будут поддерживать».
При этом видно, что майкрософт проблему, в общем и целом, осознает, и даже предпринимает «заходы» для решения. Только, не имея возможности и воли действовать путем прямого ограничения (читай, физического запрета на уровне системы делать неправильно), майки действуют со стороны административного ресурса, т.е. политическими методами. И выглядит оно, как и все подобные меры, как попытки создать цифровое гетто как для конечных пользователей (которым, стоит признать, это скорее во благо), так и для админов/разработчиков (которым это никак не во благо).
А уж по поводу «гайки закручиваются постепенно» — ну так просто отрежьте возможность запуска приложений из кешей, например, по умолчанию. Это будет первый шаг «варения лягушки». Кому это действительно понадобилось — включит. Но даже на такой шаг майки «пойтить не могут», и вот это печально, т.к. уже понятно, что «воз останется там же».
Это печально, вне всякого сомнения. Хотя думаю у такого ПО, которое используется в крупных корпорациях, просто обязанна быть версия в виде какого-нибудь MSI с поддержкой групповых политик. Ну или я отстал от жизни, и теперь всем на всё пофиг.
Есть корп-версия офиса с поддержкой групповых политик, которая позволяет, например, совершенно так же ставить в хомяк. На таких вещах как Офис «утопическая модель безопасности NT» натыкается на такую штуку, как «реальная модель монетизации», т.е. противоречит прямым интересам бизнеса. Офис 365 отличается от классического офиса тем, что это «роллинг-версия» ровно того же офиса, распространяемая по подписке на условиях «X рублей/мес с головы пользователя». Что означает «с головы пользователя» — это по лицензии на каждую учетную запись. Если я пришел к вам в гости и авторизовался на вашем компьютере под своей облачной учеткой, я имею право пользоваться офисом на вашем компьютере. А вы — человек негостеприимный, и админских прав на свой компьютер не выдали, ай-ай-ай! Что же делать? Правильно, я его в хомяк вкорячу (даже не подозревая, кстати, от этом, просто это дефолтное поведение инсталлятора, чтобы соседняя учетка ну точно-точно, никак-никак, совсем-совсем не получила доступ), и буду работать.
Ну вот такие вещи напрямую стройную практичную систему безопасности на ноль множат сходу. И майки, понимая, что ограничить это поведение «прям никак-никак», морочатся с подписями софта, чтобы иметь хоть подобие какого-то контроля. Правда платить реальную стоимость такового контроля они не готовы, не осознали, пока еще, всю ширину последствий.
Всё путём! Пойдём выпить чайку?
К сожалению, в моем городе прикупить вменяемого чайку даже за большие деньги не представляется возможным (возят откровенное гогно). При этом я не настолько фанат чая, чтобы заказывать его из далеких краев, где, по слухам, вкусный чай есть. Поэтому практически всецело перешел на кофе — он еще остался. Так что давайте по кофию!
Есть такая проблема. Хотя я вот у себя такое реализовал, но я не дикая природа.
Собственно, в этом и, имхо, правильный подход — дать рабочий инструмент и некие разумные умолчания. Инструмент, в принципе, достаточно рабочий, а вот с разумностью умолчаний, пока что, полный швах у майков.
Так они и сейчас скорее всего админы. Не знаком с разработкой нативного софта, но мне кажется, что для всяких отладчиков так и так нужны админские права.
Не, не нужны. Ни для компиляции, ни для отладчиков. В принципе, и не должны быть нужны. Разработчик — это преобразователь кофе и пончиков в код. Он может быть админом при необходимости, но совершенно не обязан им быть (тем более, что из профильного программиста хороший админ, скорее всего, не получится, тупо ценности разные). Как только организационно и финансово появляется возможность изолировать разработчиков от админских прав, это можно и нужно делать. Разработчик, по хорошему, это, с точки зрения системы, тоже пользователь, и нефиг ему за пределы своего хомяка вылазить. Пусть попу прижмет, и сидит.
объединение явного запуска файла и открытия этого файла другим приложением в один «дубль-клик» было стратегической ошибкой, исправить которую на данный момент я даже не представляю как. Так же, как и сокрытие расширения файлов по умолчанию, или политика монтирования дисков, а также очень позднее появление концепции «домашней папки пользователя» как таковойВы считаете это ошибками, а я вижу это как гениальный план по захвату рынка. Микрософту нафиг не нужна безопасность, как в линуксе, если при этом доля рынка будет такой же, как в линуксе.
Разработчик — это преобразователь кофе и пончиков в код. Как только организационно и финансово появляется возможность изолировать разработчиков от админских прав, это можно и нужно делать. Разработчик, по хорошему, это, с точки зрения системы, тоже пользователь, и нефиг ему за пределы своего хомяка вылазить. Пусть попу прижмет, и сидитДействительно, для выполнения должностных обязанностей админ-права на локалхосте не нужны.
И конторы-галеры, которые относятся к разработчикам как к рабам, не дают им права, да ещё для надёжности ставят кейлоггеры, скриншотилки и прочие DLP.
Я лично считаю админа на локалхосте нехилой такой плюшкой, которая обходится работодателю в 0 руб. (и даже идёт ещё в прибыль, т.к. программисту не надо оформлять заявку в отдел администрирования, чтобы моему юзеру перенастроили HTTP ACL для дебага очередного сервиса на локалхосте).
Вы считаете это ошибками, а я вижу это как гениальный план по захвату рынка.
Гениальный план по захвату рынка на 99% состоял из использования административного ресурса и массового задействования рыночных механизмов, начиная с демпинга. Снимите уже розовые очки, дубль-клик не в майкрософте придуман.
Действительно, для выполнения должностных обязанностей админ-права на локалхосте не нужны.
И конторы-галеры, которые относятся к разработчикам как к рабам, не дают им права, да ещё для надёжности ставят кейлоггеры, скриншотилки и прочие DLP.
Вы — юный максималист анархического толка, и не имеете склонности к анализу системы в целом.
Если галеры существуют, и туда идут работать — значит, это кому-нибудь нужно. На этом рассуждения о пагубности и ненужности галер можно сворачивать.
Я лично считаю админа на локалхосте нехилой такой плюшкой, которая обходится работодателю в 0 руб. (и даже идёт ещё в прибыль, т.к. программисту не надо оформлять заявку в отдел администрирования, чтобы моему юзеру перенастроили HTTP ACL для дебага очередного сервиса на локалхосте).
Вы еще и идеалист… Запущенный случай. Даже мой относительно небольшой опыт утверждает, что цена есть у всего, даже у «админа на локалхосте», и она ненулевая.
Да включите уже, наконец, голову. Что означает «админ на локалхосте»? Это означает, что у программиста есть доступ ко всем «крутилкам» на его компьютере, а значит, либо программист сам собственноручно админит свой компьютер, либо штатный админ при устранении неполадок вместо того, чтобы действовать по установленным регламентам, разбирается, что там «накрутил» программист.
Теперь просто сравните среднюю зарплату программиста со средней зарплатой админа. Предположим, штатного админа нет, и «каждый сам себе админ». Значит, работу, которую мог бы выполнить администратор, выполняет программист. А у вас не галеры, т.е. выполняет он эту работу, очевидно, в рабочее время за программистскую зарплату. Вот разница в зарплате между программистом и «эникейщиком» — это стоимость вашего «админа локалхоста за 0 руб». Там всяко не 0 рублей выходит.
Теперь возьмем другую ситуацию — админ есть, но ему прямо запрещено отбирать админские права у разработчиков. Разработчик «крутит крутилку», и админ идет разгребать. Ну так вот, политик у вам нету, т.е. каждый косяк — явная штучная ситуация. И эникейщик в ней уже не разберется, придется взять админа подороже, либо смириться с тем, что админ будет чинить «я ничего не делал» дольше. Дальше считаете возрастающие расходы на администрирование и плачете. Там тоже не 0 выходит.
Этими «галерами» не клинические идиоты управляют. Они могут тысячу раз ничего не понимать в разработке, но они гарантированно умеют считать деньги. И вот если они отказываются от бесплатных «админов локалхостов» и нанимают сверху человека, который у вышеупомянутых админов локалхостов админские права отбирает, потом чинит за них и вместо них, и все это за зарплату, то происходит это ровно по одной причине — так дешевле. Не в ваших фантазиях дешевле, а реально, проверенно на практике дешевле, причем известно даже насколько дешевле, с точностью до десятых долей копейки.
выполняет он эту работу, очевидно, в рабочее время за программистскую зарплату. Вот разница в зарплате между программистом и «эникейщиком» — это стоимость вашего «админа локалхоста за 0 руб»Так, пока рабочее место настраивается, программист сидит курит. Или, вы думаете, админ настолько быстрее справляется, что оправдывает свою з/п на разнице в затраченном времени.
Этими «галерами» не клинические идиоты управляют. Они могут тысячу раз ничего не понимать в разработке, но они гарантированно умеют считать деньгиРечь не о взгляде со стороны бизнеса, с его стороны, возможно, и есть выгода. Также, как Яндекс-такси дожимает бедных водителей, или шахтёрам денег не платят ровно столько, сколько это терпит губернатор. Все эти адские места существуют, аналогично как «галеры существуют, и туда идут работать — значит, это кому-нибудь нужно»
Так, пока рабочее место настраивается, программист сидит курит. Или, вы думаете, админ настолько быстрее справляется, что оправдывает свою з/п на разнице в затраченном времени.
Вот именно! Вы же сами все поняли! До тех пор, пока админ не окупает свою зарплату, его никто и не нанимает же!
Речь не о взгляде со стороны бизнеса, с его стороны, возможно, и есть выгода. Также, как Яндекс-такси дожимает бедных водителей, или шахтёрам денег не платят ровно столько, сколько это терпит губернатор. Все эти адские места существуют, аналогично как «галеры существуют, и туда идут работать — значит, это кому-нибудь нужно»
Сейчас вы очень сильно опечалитесь, конечно, но речь ровно о взгляде со стороны бизнеса. Если вам платят зарплату, значит это кому-нибудь нужно. Альтернативный вариант — никому не нужно платить вам зарплату, и вы сидите без денег. «Кто девочку танцует, тот ее и провожает».
шахтёрам денег не платят ровно столько, сколько это терпит губернатор
Популизм какой-то. «А царь? А царь добрый! Просто он не знает!»
То есть, вы оправдываете все эти потогонки, заявляете, что плохие условия труда для работников, но выгодные бизнесу, это нормально, это так и должно быть?
В принципе, можете и дальше их оправдывать. Мне с ними не по пути. Пройду мимо.
Разные есть бизнес-модели. Кому-то проще нагнать индусов и поставить погонщиков-надсмотрщиков. Кто-то наоборот, устраивает всякую роскошь типа массажных кабинетов и игровых комнат. Не надо заявлять, что положение дел, ведущее к быстрой прибыли, единственно верное.
В принципе, можете и дальше их оправдывать. Мне с ними не по пути. Пройду мимо.
Разные есть бизнес-модели. Кому-то проще нагнать индусов и поставить погонщиков-надсмотрщиков. Кто-то наоборот, устраивает всякую роскошь типа массажных кабинетов и игровых комнат. Не надо заявлять, что положение дел, ведущее к быстрой прибыли, единственно верное.
То есть, вы оправдываете все эти потогонки, заявляете, что плохие условия труда для работников, но выгодные бизнесу, это нормально, это так и должно быть?
Собственно, рабство в целом отменили уже достаточно давно, а в виде крепостного права в России «де юре» — с 1861 года, «де факто» — с 1917. В связи с этим, работника а) никто силой на галеру не заволакивает, б) никто к стулу не приковывает. Если люди там сидят, значит, им норм. Что не так?
В принципе, можете и дальше их оправдывать. Мне с ними не по пути. Пройду мимо.
Рад за вас, юношеско-максималистичный вы наш.
Разные есть бизнес-модели. Кому-то проще нагнать индусов и поставить погонщиков-надсмотрщиков. Кто-то наоборот, устраивает всякую роскошь типа массажных кабинетов и игровых комнат. Не надо заявлять, что положение дел, ведущее к быстрой прибыли, единственно верное.
Про «единственно верное» — это не мои слова. Ваши скорее. Про альтернативные пути развития я ни слова не говорил, я говорил конкретно про «ужасные рабские галеры» — в них нет, по сути, ничего вопиюще-плохого. Обобщать частное представление на целое — вообще не мой конек. Это вы однозначно осуждаете «галеры» и стоите на безусловных позициях «свобода или смерть». Я человек старый, женатый, есть ребенок — я менее максималистичен и склонен рабочие места оценивать исключительно через призму личных шкурных интересов. Если по совокупности получаемых от работы профитов «галера» окажется для меня привлекательней «маленького, но гордого коллектива голодных разработчиков» — я предпочту устроиться на галеру, и не спеша грести там. Искренне не вижу, что плохого в «галерах» как сущности, что их нужно так решительно осуждать. Так можно договориться, что демократия — единственно приемлемая форма управления, безусловно превосходящая все остальные. Свят-свят.
UFO just landed and posted this here
А вот тут нет никаких проблем. Исполняемые файлы могут лежать в Program Files, а данные учётной записи в профиле. И тогда при заходе из другого профиля просто попросят ввести эти учётные данные.
Проблема только одна: сама концепция пользовательских профилей в широком применении на винде появилась достаточно поздно. В домашних системах, емнип, с Windows XP, притом в достаточно куцем варианте. Полноценные профили — это уже ажно Windows7. Притом, откуда эти самые профили «завезли» тоже понятно. И вот дальше чужеродную nix-философию стали натягивать на то, что уже накопилось, стараясь не поломать то, что уже работает. Короче, ситуация патовая в хлам.
Ну а, собственно, по поводу того, как заставить софтину, не рассчитанную на работу из ProgramFiles, работать внутри хомяка — есть workdir, т.е., по сути, проблема, в принципе, решаема. Но удобного инструмента под это нет. И не будет, по очевидным системам.
Согласен, проблемы в умолчаниях, которые нельзя поменять по причинам совместимости.
И еще одна вещь — периодическая невозможность использовать разумные настройки в рамках сложившихся условий. Всегда найдется какая-нибудь ну-очень-важная-фигня, которая откажется работать в условиях разумных ограничений прав.
UFO just landed and posted this here
В смысле в куцем? Не припомню никаких отличий между XP и последующими версиями, кроме UAC, который суть костыль.
Ну, собственно, «классика» выглядит как «у пользователя есть хомяк, за пределы которого он не может вылезти». В windows — слабо-реализуемо, хотя бы из-за особенностей иерархии файловой системы.
Это, как бы ядро NT с самого своего зарождения приспособлено для работы в многопользовательской среде, это одно из требований к его разработке. И проблем с профилями никаких нет.
Это, как бы ядро NT получило широкое пользовательское распространение именно на этапе Windows XP. 2000, NT 3,4,4.5 — таки экзотика для пользовательских компьютеров.
Ну и, собственно, проблемы с профилями таки есть. Они «текут» по дефолту.
UFO just landed and posted this here
Для системы с одним диском всё это работает прекрасно.
Ага, а для системы с несколькими — никак.
А как на Linux помогает монтирование в каталоги (что доступно и на Windows) я ума не приложу.
Ну, собственно, я пользователю просто «в тупую» монтирую диск в качестве «хомяка». В винде есть «ряд нюансов».
Ага, а для системы с несколькими — никак.
/usr/bin
/bin
/usr/sbin
/sbin
/usr/local/bin
/usr/local/sbin
/optчто вы про «однозначные» и «правильные» методики говорите?
Я ждал, я ждал! Еще про «файлы, начинающиеся с точки — скрытые» вспомните!)))
Один нюанс: «Я таки ни в едином моменте не утверждал, что у нас тут не говно! Я таки говорил, что у вас — говно»))))
В общем и целом — с точки зрения изоляции сеанса nix-системы сделаны несколько удачней. Даже с теми же дисками — пользователь просто не обладает информации о наличии у него таковых. У пользователя есть хомяк. Что там в него намонтировано и откуда — да админ его знает. Диски — это «плохая абстракция». С детства помню «под игрушки — диск D:, под фильмы — диск E:». И извечная проблема с Program Files (в текущем контексте хрен-разрешимая) — Program Files — это папка на диске C:. А диск C: — маленький, диск C: — беречь надо.
Собственно, проблемы то стоят одинаковые, решаются несколько по-разному. На выходе — везде хреново, но с разной степенью хреновости. Если в nix-лагере на достаточно раннем этапе сложилась философия «каждому пользователю по хомяку» и проблема нехватки места при наличии FHS, хард/сим линков и точек монтирования решилась без нарушения концепции «пользователь в хомяке», то в Windows подключение дополнительного диска влекло (и до сих пор влечет) размытие этой концепции.
К тому же расположение «хомяка» на системном диске (а в штатных инструментах установки, вроде, нет возможности без приседаний унести «хомяк» в другой раздел) в свете постепенного переползания всего и вся на SSD снова «ставит ребром» вопрос экономии места и переносимости профилей.
В общем, на каждом витке развития порождаются новые «болячки», которые windows традиционно «энтерпрайзненько» решает, а тот же linux остается кондовой суровой штукой, смотанной синей* изолентой.
— * — синяя изолента как пример самого прочного вещества в известной вселенной.)))
что вы про «однозначные» и «правильные» методики говорите?
Один нюанс: «Я таки ни в едином моменте не утверждал, что у нас тут не говно! Я таки говорил, что у вас — говно»))))
В общем и целом — с точки зрения изоляции сеанса nix-системы сделаны несколько удачней. Даже с теми же дисками — пользователь просто не обладает информации о наличии у него таковых. У пользователя есть хомяк. Что там в него намонтировано и откуда — да админ его знает. Диски — это «плохая абстракция». С детства помню «под игрушки — диск D:, под фильмы — диск E:». И извечная проблема с Program Files (в текущем контексте хрен-разрешимая) — Program Files — это папка на диске C:. А диск C: — маленький, диск C: — беречь надо.
Собственно, проблемы то стоят одинаковые, решаются несколько по-разному. На выходе — везде хреново, но с разной степенью хреновости. Если в nix-лагере на достаточно раннем этапе сложилась философия «каждому пользователю по хомяку» и проблема нехватки места при наличии FHS, хард/сим линков и точек монтирования решилась без нарушения концепции «пользователь в хомяке», то в Windows подключение дополнительного диска влекло (и до сих пор влечет) размытие этой концепции.
К тому же расположение «хомяка» на системном диске (а в штатных инструментах установки, вроде, нет возможности без приседаний унести «хомяк» в другой раздел) в свете постепенного переползания всего и вся на SSD снова «ставит ребром» вопрос экономии места и переносимости профилей.
В общем, на каждом витке развития порождаются новые «болячки», которые windows традиционно «энтерпрайзненько» решает, а тот же linux остается кондовой суровой штукой, смотанной синей* изолентой.
— * — синяя изолента как пример самого прочного вещества в известной вселенной.)))
В общем и целом — с точки зрения изоляции сеанса nix-системы сделаны несколько удачней. Даже с теми же дисками — пользователь просто не обладает информации о наличии у него таковых. У пользователя есть хомяк. Что там в него намонтировано и откуда — да админ его знает. Диски — это «плохая абстракция». С детства помню «под игрушки — диск D:, под фильмы — диск E:Стоп-стоп, вы определитесь, речь о домашнем компе или как? Если о домашнем, то юзер сам себе админ и свободно разложит по дискам свои кинчики и игрушечки. И на отдельных дисках их держать удобнее, чем все смонтированное в один хомяк. Хотя бы из соображений резервирования и переноски на другие места.
А в ентерпрайзе виндовые админы легко легко перемещают профили куда угодно, хоть на сетевые диски и монтируют всё не хуже, чем юниксах.
UFO just landed and posted this here
И на отдельных дисках их держать удобнее, чем все смонтированное в один хомяк.
Ай не факт, чесслово!
А в ентерпрайзе виндовые админы легко легко перемещают профили куда угодно, хоть на сетевые диски и монтируют всё не хуже, чем юниксах.
Ну не так все просто, однако же.
Но в целом проблемы решаемы — ага.
К тому же расположение «хомяка» на системном диске (а в штатных инструментах установки, вроде, нет возможности без приседаний унести «хомяк» в другой раздел
можно штатно перенести. Но был случай — при малейшем глюке этот путь теряется и винда падает по-настоящему
ну, вот я об этом примерно. Скажем так, все мои (немногочисленные, справедливости ради) эксперименты с переносом хомяка на отличный от системного раздел, заканчивались достаточно плачевно и в достаточно сжатые сроки.
У меня вообще сложилось впечатление, что этот механизм не особо рабочий, начиная с того «нюанса», что некоторые программы почему-то продолжают «срать» в прежний «хомяк» на системном разделе.
Я не исключаю вероятности, что программы написаны некорректно (условно вместо %UserHome%\some\relative\path используют извращения вида C:\\Пользователи и как оно там\%UserName%\some\relative\path), однако конкретно эта болячка в линухе не проявляется (не говорю, что там нет других, тысячи их, но от этой пользователь застрахован).
Скажем так, свои «причуды» есть везде. Просто подача «да в винде можно все то же, что и в линуксе, и ничуть не хуже» — она странная. Можно, но не все, и сильно не всегда «не хуже». При этом я отлично понимаю и обратную вещь: «в линуксе не всегда, не все, и совершенно не гарантированно лучше». Я про NTFS-права прямо так и говорю: линуксовые rwx не покрывают и половины того, что умеет NTFS. Делает ли это NTFS-атрибуты лучше, чем rwx? Да вот ни разу, т.к. а) модель разная, для разных применений, б) для многих кейсов NTFS избыточна, в) не все комбинации rwx могут быть покрыты NTFS-атрибутами.
У меня вообще сложилось впечатление, что этот механизм не особо рабочий, начиная с того «нюанса», что некоторые программы почему-то продолжают «срать» в прежний «хомяк» на системном разделе.
Я не исключаю вероятности, что программы написаны некорректно (условно вместо %UserHome%\some\relative\path используют извращения вида C:\\Пользователи и как оно там\%UserName%\some\relative\path), однако конкретно эта болячка в линухе не проявляется (не говорю, что там нет других, тысячи их, но от этой пользователь застрахован).
Скажем так, свои «причуды» есть везде. Просто подача «да в винде можно все то же, что и в линуксе, и ничуть не хуже» — она странная. Можно, но не все, и сильно не всегда «не хуже». При этом я отлично понимаю и обратную вещь: «в линуксе не всегда, не все, и совершенно не гарантированно лучше». Я про NTFS-права прямо так и говорю: линуксовые rwx не покрывают и половины того, что умеет NTFS. Делает ли это NTFS-атрибуты лучше, чем rwx? Да вот ни разу, т.к. а) модель разная, для разных применений, б) для многих кейсов NTFS избыточна, в) не все комбинации rwx могут быть покрыты NTFS-атрибутами.
Даже с теми же дисками — пользователь просто не обладает информации о наличии у него таковых.Да, конечно, df не завезли.
В общем и целом — с точки зрения изоляции сеанса nix-системы сделаны несколько удачней.Вы ведь путаете 2 несвязанные сущности: сессия пользователя и файловая система. Многопользовательская среда с разделением сессий реализована в Windows давно.
Что касается различий в монтировании ФС, то монтирование всего от корня имеет свои недостатки: вам необходимо заранее предусмотреть, куда будет монтироваться новый диск или флешка. Да, сейчас уже придумали, что есть /cdrom или на рабочем столе появляется иконка смонтированного диска (а иначе где пользователю искать 2ой DVD-ROM или флешку?). Но в чем тогда преимущество монтирования от корня и отличие от назначения буквы диска? Считайте, что c:\ — это /c, d:\ — это /d и т.д. Гибкость монтированная диска или раздела в пользовательскую папку не очень часто востребована в домашнем варианте использования.
А для корпоративного работает перенаправление папок (да и для домашнего тоже — но требует какого-то уровня знаний, к-рого странно *требовать* от клиента).
Более того, вы можете реализовать это монтирование от корня в Windows — но нужно это весьма редко. Тем более, что инструмент библиотек в Windows значительно более гибок: он собирает в одной виртуальной папке все папки, привязанные к нему. То есть Фильмы могут быть раскиданы по 3-4-… дискам — я вижу их все в одной папке Видео. Тут уже вообще без разницы, как происходит монтирование файловых систем/разделов:
Библиотеки
UFO just landed and posted this here
Да, конечно, df не завезли.
Да, конечно, рядовой пользователь первым делом запускает df))). И, конечно, у каждого, без исключения, пользователя есть права на чтение содержимого /dev…
Вы ведь путаете 2 несвязанные сущности: сессия пользователя и файловая система.
Поверьте, не путаю. Отлично понимаю, чем «домашний каталог пользователя» отличается от «сессии пользователя». Преимущества хранения, например, настроек сессии и всех юзеро-специфичных настроек софты в домашней папке пользователя над тем же общесистемным реестром, равно как и недостатки подхода, тоже представляю.
Что касается различий в монтировании ФС, то монтирование всего от корня имеет свои недостатки: вам необходимо заранее предусмотреть, куда будет монтироваться новый диск или флешка.
FHS — слой абстракции, который, очевидно, имеет равно как преимущества (например, то, что это слой абстракции), так и недостатки (например, то, что это слой абстракции). Если ваша задача — очевидным и непротиворечивым образом изолировать сеансы и рабочие пространства пользователей друг от друга, FHS удобней. Мне кажется, это очевидно. Начиная от единой точки входа в рабочее пространство пользователя (aka «хомяк»), которое позволяет напрямую разрешить пользователю делать все, что он придумает, внутри этого пространства (если вы заперли пользователя в «хомяке» — это гарантия того, что другим пользователям он навредить не сможет. Если смог — плохо заперли). Ну и заканчивая возможностью монтирования устройств для конкретного пользователя, например. Т.е. вы можете подмонтировать диск таким образом, что он будет существовать ровно для одного пользователя, причем регулировать это можно «втупую» точкой монтирования. При наличии на верхнем уровне иерархии тома ФС, а также механизма автомонтирования, такой «финт ушами» становится слабоосуществим.
С другой стороны, если и явные недостатки относительно «конкурента». Они проявляются в противоположные моменты, т.е. когда нужно не изолировать рабочие пространства, а наоборот — дать нескольким пользователям доступ к какому-то единому ресурсу. Вот тут FHS не то чтобы прямо совсем «сдувается», но таки а) rwx становится критично недостаточно, б) все это требует дополнительных приседаний в виде «монтируй то, монтируй это, пили симлинки» или выпускай уже пользователя за пределы «хомяка», в) все преимущества FHS резко сходят на нет, читай нивелируются.
Ну а про «вам необходимо заранее предусмотреть, куда будет монтироваться новый диск или флешка.» Тут вы слегка припоздали: udev есть, и даже работает.
Да, сейчас уже придумали, что есть /cdrom или на рабочем столе появляется иконка смонтированного диска (а иначе где пользователю искать 2ой DVD-ROM или флешку?).
Кхм, не… Придумали несколько больше уже. Целый udev придумали…
Но в чем тогда преимущество монтирования от корня и отличие от назначения буквы диска? Считайте, что c:\ — это /c, d:\ — это /d и т.д.
Ну, например, пару-тройку преимуществ я сейчас назову.
1. «Хомяк» пользователя — это его реальное рабочее пространство. Сейчас все дружно на SSD переползают, они дорогие, например. Дефолтное расположение «хомяка» — системный диск, а он маленький. Да, вы сейчас расскажете мне, что профиль пользователя можно перенести на другой диск. А я вам отвечу, что это а) очень нетривиально, б) нетривиально до уровня неподъемной сложности более-менее рядовым пользователем, в) работает хреново. Вот честное слово, штатными средствами переносил, ни разу по-человечьи не заработало, всегда что-то падало, иногда до невозможности выведения системы из коматоза. К тому же один хрен у вас останется некоторое количество программ, которые будут упорно «испражняться» по прямому пути в C:\Users\%userName%, и это вам уже не победить. Многолетняя привычка ходить по абсолютным путям от буквы диска начиная порождает соответствующие проблемы.
А само предложение «оставьте хомяк где есть, а фильмы в явную храните на другом диске» просто делит на ноль саму концепцию «рабочего пространства пользователя». Зачем отдельная установленная папка вообще, если данные пользователя равномерным слоем размазаны по 100500 дисков и эта взаимосвязь никак не прослеживается автоматически?
2. Унификация.
Все пользовательские данные в пределах «хомяка» — это прекрасно же. Элементарно забекапить — просто натравить dd на хомяк пользователя. Вернуть из бекапа — натравить dd в обратную сторону. Не «проверить, где лежит хомяк, собрать все, связанное с пользователем из реестра и пробежаться по всем дискам в поисках, где и чего он писал», а просто забекапить «хомяк».
При этом четко определенная иерархия дает гарантию того, что на другой машине ровно то же будет лежать по тем же путям и в том же порядке. И неважно, на каком диске оно будет лежать физически, важно то, что `rm -rf ~/*` будет иметь совершенно одинаковый эффект на всех машинах парка.
3. Отсюда третий бонус: переносимость.
Скрипт, единожды написанный для издевательства над пользователем (т.е. автоматизации рутинных процессов) можно тупо взять, положить на другую машину, не задумываясь даже, в каком порядке к ней и какие диски подключались, и запустить. Вероятнее всего, он просто заработает, и заработает так, как надо. Честно, унифицированные пути — это очень удобно!
А в целом — да, все более-менее решаемо. Но не все, и не все удачно.
Гибкость монтированная диска или раздела в пользовательскую папку не очень часто востребована в домашнем варианте использования.
Ну вот, «нам это не нужно»…
А для корпоративного работает перенаправление папок (да и для домашнего тоже — но требует какого-то уровня знаний, к-рого странно *требовать* от клиента).
Это которое через AD? Честное слово, имхо, немного «из пушки по воробьям».
Тем более, что инструмент библиотек в Windows значительно более гибок: он собирает в одной виртуальной папке все папки, привязанные к нему. То есть Фильмы могут быть раскиданы по 3-4-… дискам — я вижу их все в одной папке Видео. Тут уже вообще без разницы, как происходит монтирование файловых систем/разделов
Сканирование всех папок компьютера по таймеру и ведение базы данных файлов — ну, такая себе замена монтированию. Правда. Медленно, ресурсоемко (помните, этот «кеш» хранится только на системном диске), не предоставляет вменяемого инструментария для пакетной обработки. Ну, в общем, мне лично кажется странным предлагать скрипт, прикрученный сбоку и по таймеру обновляющий базу данных в качестве альтернативы иерархической файловой системе…
UFO just landed and posted this here
Рецепт победы прост — симлинк с того пути на его актуальное положение. Работает для 99,99% софта.
Ну, какбы, целиком положить симлинк вместо хомяка — низзя, винда может обидеться. А симлинкать придется каждый конкретный косячный путь. А некоторые программы при обновлении любят удалить целиком папку с предыдущей инсталляцией (читай, ваш симлинк) и установиться заново.
Ну, короче, такая себе победа. «С такими друзьями враги не нужны». Да и вообще, штатный механизм системы, который работает для 90% софта «из коробки», для 9,99% софта требует подпирания костылем, а для оставшихся не работает вообще. Такое себе. Вы же должны признать, что с этой частью в винде не все в порядке.
UFO just landed and posted this here
ХЗ, не встречал косячных прог
Счастливчик…
Собственно, подскажу, где искать. Берете любую прогу, которая была написана под WinXP или более раннюю версию операционки. «Users» в ту эпоху называлась «Documents&Settings», и именно туда было принято складывать пользовательскую фигню. Да, майки позаботились об «обратной совместимости» — Documents&Settings нынче симлинк на Users. Отличненько, переносим профиль пользователя на не-системный диск. Профиль теперь на диске, например, D:, а старая прога упорно стучит в Documents&Settings, по симлинку редиректится в C:\Users и срет в старый путь профиля. Потому что ей никто не сказал, что профиль перенесли. Симлинкать же профиль целиком — периодически приводит к «окирпичиванию» системы.
но этих путей не так уж и много.
Ну да, по паре-тройке на каждую «специфическую программу». Накопите 10 штук на парке из 50 машин, попробуйте повторить фразу — язык же не повернется.
Из неперенесённого остались только Сохранённые игры, куда по наивняку сложила сейвы целая одна игрушка.
Ну очевидно же: поставьте побольше игрушек, чтобы почувствовать масштаб.
Собственно, эти нюансы с реальным местоположением файлов в линуксах находятся под уровнем абстракции между непосредственно ФС и прикладным уровнем. Это удобно, например, хотя бы тем, что нет необходимости в отдельном инструменте «миграции профиля пользователя».
Покажите мне программу, которая удаляет целиком каталог документов, или там музыки.
Если подойти к вопросу формально — тысячи их! Гуглите «вирусы-шифровальщики», например.
А в целом, я не про удаление документов. Я про симлинканье профиля самой программы. Т.е. я беру, профиль программы симлинкаю в другой раздел, программа обновляется — вуаля симлинк удален, профиль лежит на системном диске. Ну налицо же протекающая абстракция.
Хотя очевидно, проблема в разработчиках (да, опять), которые не осилили переменные пути.
Проблема, для начала, в разработчиках, которые не осилили концептуально-целостную реализацию «переменных путей». Есть «C:\Users\%username%», есть "%userprofile%", есть "%system%\Documents and Settings\%username%" — тысячи их. И все они по дефолту ведут в одно и то же место. Как только вы отходите от дефолтов, возникают проблемы. Тут уже выше упоминали: /usr/bin:/usr/sbin:/usr/local/bin:/bin:/sbin и прочие «уродливые месте этих ваших линуксов». Но у этих уродливых мест существует одно оправдание: они работают, действительно работают.
Какое оправдание у windows, у которого штатный механизм миграции профиля пользователя работает не до конца и с сюрпризами? Это сторонние разработчики, очевидно, документацию не дочитали? Ну ок, идем в документацию: «Профили пользователя хранятся в C:\Users» — вуаля, мы только что сломали нашу программу под windows 7. Ну, такое себе, чесслово. Вы вот мне можете прямо сейчас подсказать универсальный, стопудово работающий способ определить местоположение «хомяка» пользователя, позволяющий мне не заморачиваться, на какой версии одной и той же операционной системы мой софт будет запускаться? Ну вот там все нетривиально, например. В линухе — '~' или /home/%username%. Есть что-то настолько же простое и постоянное на протяжении сколько-нибудь значимого времени (лет 5 хотя бы) в винде?
Но ваши проценты отнюдь неверны. Лично я у себя не нашёл ни одного артефакта, хотя никаких симлинков не создавал.
Лично вы — отличная релевантная выборка, так точно. Просто попробуйте поюзать софт, писавшийся под WinXP (подскажу, в дикой корпоративной природе его много).
Преимущества хранения, например, настроек сессии и всех юзеро-специфичных настроек софты в домашней папке пользователя над тем же общесистемным реестром, равно как и недостатки подхода, тоже представляю.Представляете, но ошибаетесь. Пользовательские настройки хранятся в кусте реестра пользователя, к-рый хранится в профиле пользователя (ntuser.dat).
Начиная от единой точки входа в рабочее пространство… — плохо заперли).извините, но тут очень много «воды». Если вам нужно ограничить пользователя на станции, то, чаще всего, это либо терминальный сервер, либо ПК общего доступа. в обоих случаях с помощью групповых (AD) или локальных политик вы обеспечиваете необходимое сокрытие данных. Во 2ом случае вы можете использовать еще и обязательные профили. Вот уж чего-чего, а жалоб на возможности по ограничению пользователей в корп среде я не наблюдал.
Это которое через AD? Честное слово, имхо, немного «из пушки по воробьям».используйте локальные политики. Просто без AD вы заводите пользователей вручную — при создании и профили можете перенаправить.
«Хомяк» пользователя — это его реальное рабочее пространство. Сейчас все дружно на SSD переползают, они дорогие, например.еще раз — сформулируйте реальный кейс. а то у вас смешение «дом»-«работа». Дома чаще всего и linux, и windows ставят все-на-один-раздел — просто потому, что end user не будет там заморачиваться, сколько ему на swap, сколько на boot и сколько на root «отрезать». а на работе — folder redirection if required.
А само предложение «оставьте хомяк где есть, а фильмы в явную храните на другом диске» просто делит на ноль саму концепцию «рабочего пространства пользователя». Зачем отдельная установленная папка вообще, если данные пользователя равномерным слоем размазаны по 100500 дисков и эта взаимосвязь никак не прослеживается автоматически?
Все пользовательские данные в пределах «хомяка» — это прекрасно же. Элементарно забекапить — просто натравить dd на хомяк пользователя
Я не понимаю, какую вы задачу решаете? Вы хотите натянуть админские подходы к организации работы множества пользователей на домашний компьютер?
Если компьютер персональный, то там все диски — хомяк.
Если он семейный, то какой смысл изолировать фильмы (фотографии) от других пользователей.
Бекапить весь хомяк и одновременно рекомендовать хранить там фильмы — ну, такое…
UFO just landed and posted this here
Ага, а для системы с несколькими — никак.А в чём проблема настроить? В винде корень системного диска недоступен для записи юзерам, но доступен на чтение (как и в линукс).
Но для удобства корни других разделов доступны в r/w. Сделайте просто настройки прав на каждый корень, и будет как в линуксе.
UFO just landed and posted this here
Есть ещё маленький секрет — диски в Windows можно монтировать в каталоги. Замещать системные каталоги так не следует, но для любого пользовательского вполне себе работает.
Ну вот я и говорю — «есть-то оно есть, но работает не везде, не со всем, и вообще использование, как говорится, сопряжено...» Т.е., вроде как, механизм и есть, и вроде как не совсем рабочий…
Но для удобства корни других разделов доступны в r/w. Сделайте просто настройки прав на каждый корень, и будет как в линуксе.
Ну да, «повторите операцию N раз» и «не забывайте повторять при каждом подключении диска».
Проблема только одна: сама концепция пользовательских профилей в широком применении на винде появилась достаточно поздно. В домашних системах, емнип, с Windows XP, притом в достаточно куцем варианте. Полноценные профили — это уже ажно Windows7Ещё в NT4 можно было сесть за любой компьютер в сетке, залогиниться доменной учёткой и получить свой рабочий стол, данные и программы. Далее была Win2000, а XP та же 2k с цветастыми непрямоугольными кнопками.
В XP профили есть в полной мере.
Проблема домашних систем от MS в том, что домашние пользователи все поголовно сидят под админом, поэтому профили и их изоляция не имеет смысла. Это стали затыкать костылями типа UAC и бредовыми настройками ACL, что прав админа недостаточно, чтобы лезть в систему, права SYSTEM выше.
Ну, собственно, «классика» выглядит как «у пользователя есть хомяк, за пределы которого он не может вылезти». В windows — слабо-реализуемо, хотя бы из-за особенностей иерархии файловой системы.Ээээ… Не понял. Уберите у юзера права админа и он будет вечно сидеть в своём хомяке.
UFO just landed and posted this here
Ты ж мой умница! Посмотрите, все с первого раза понимает!))))
Опять же, если это семейный ноутбук, ну будет общая свалка файлов мужа и жены на одном диске, в чём проблема? Вы хотите их заставить изучать права и монтирование? Так вы ОСь не продадите.
А кому надо, зайдут в свойства и выставят разрешения, делов на 2 минуты. Кинут юзерам на рабочие столы ярлыки на разрешённые папки на втором диске, чтобы не искали, и вся настройка.
А кому надо, зайдут в свойства и выставят разрешения, делов на 2 минуты. Кинут юзерам на рабочие столы ярлыки на разрешённые папки на втором диске, чтобы не искали, и вся настройка.
Опять же, если это семейный ноутбук, ну будет общая свалка файлов мужа и жены на одном диске, в чём проблема? Вы хотите их заставить изучать права и монтирование? Так вы ОСь не продадите.
Если это «семейный ноутбук», до «свалки файлов мужа и жены на одном диске» обычно не доходит, у них учетка одна. «А как же разные профили в одноклассниках» — спросите вы? Голь на выдумки хитра! — остроумно отвечу я вам. — У них разные браузеры!
А кому надо, зайдут в свойства и выставят разрешения, делов на 2 минуты. Кинут юзерам на рабочие столы ярлыки на разрешённые папки на втором диске, чтобы не искали, и вся настройка.
Не, не кинут. В чужой хомяк не смогут, потому что туда прав писать нету. Просто заставят заучить «D:\Разное\Фильмы\ФильмыЖены\Свадьба\2019».
Просто это совсем уже какие-то крайние случаи демократии, этим конкретным людям ни FHS, ни распределение прав не нужны. Да и понятие «многопользовательская система» для них настолько далеко, что вот на их случай все равно никто ничего не предусматривал.
UFO just landed and posted this here
Не, не кинут. В чужой хомяк не смогут, потому что туда прав писать нетуТак один из юзеров в этом сценарии так или иначе админ. Он и права настроит, и ярлыки бросит.
А теперь предположим, что семья большая, пусть будет 50 человек. И надо каждому на рабочий стол ярлыки разложить. А системный диск — маленький, поэтому половина профили на другие диски смигрировала, а остальные — кто симлинков понавтыкал, кто еще как изголялся.
Была бы иерархическая ФС — проблем бы не было: просто циклом пробегаем по подкаталогам /home. А тут как?
Была бы иерархическая ФС — проблем бы не было: просто циклом пробегаем по подкаталогам /home. А тут как?
50 чел семья и 1 ПК. Очень рабочий кейс. Ну да не суть — перенаправляете профили — уж на 50 -сотрудников- членов семьи 1 админ найдётся.
А тут как?Такой «семье» пора заводить домен и политики.
Была бы иерархическая ФС — проблем бы не было: просто циклом пробегаем по подкаталогам /home. А тут как?Побегать скриптом powershell по юзерам, и по их %USERPROFILE%
А теперь предположим, что семья большая, пусть будет 50 человек. И надо каждому на рабочий стол ярлыки разложить.
1) это цыгане
2) а профили на что?
2.2) папку на стол, в ней ярлыки на нужные проги
Ещё в NT4 можно было сесть за любой компьютер в сетке, залогиниться доменной учёткой и получить свой рабочий стол, данные и программы. Далее была Win2000, а XP та же 2k с цветастыми непрямоугольными кнопками.
Не отрицаю, но все вышеперечисленное до «массового прихода winXP» домашними пользователями не использовалось в сколько-нибудь значимых количествах.
Проблема домашних систем от MS в том, что домашние пользователи все поголовно сидят под админом, поэтому профили и их изоляция не имеет смысла. Это стали затыкать костылями типа UAC и бредовыми настройками ACL, что прав админа недостаточно, чтобы лезть в систему, права SYSTEM выше.
Вот и я говорю, что UAC — костыль, дефолтные настройки — бредовые. Там вообще много «странного».
Ээээ… Не понял. Уберите у юзера права админа и он будет вечно сидеть в своём хомяке.
Второй диск цепляете — вуаля, коммунизм и демократия.
Второй диск цепляете — вуаля, коммунизм и демократия.В линуксе флешки юзерам нельзя втыкать? Для монтирования обязательны права админа?
В линуксе флешки юзерам нельзя втыкать? Для монтирования обязательны права админа?
Можно. Флешки — можно. В чем суть проблемы-то? Подмонтируется оно в /media/%currentUserName%/длинный-такой-uid-флешки. Симлинк на оное сразу всплывет в файловом менеджере. К слову, соседний в параллель залогиненный пользователь по дефолту на флешку права не получит, например. Права уходят тому, чей сеанс активен в момент подключения. Политики изменяемы. С флешками все хорошо, короче, можете расслабиться.
Это в корп-секторе, да и то мало кто заморачивается. А на домашних компьютерах — нереально. И вся разница сводится к тому, что в linux-системах вы явным образом «исполняете» файл, а в windows вы просто «дубль-кликаете». Просто вектор атаки «на дурака» отсекается.
Как ни крути, явное разделение исполнения и открытия/просмотра файла — явное благо, и в винду не завезли ровно по одной причине — пользователь привык к дубль-клику. Иногда есть ошибочные решения, принятые на более ранних этапах (и в этих наших линуксах тоже, ага), от которых очень сложно избавиться.
Как ни крути, явное разделение исполнения и открытия/просмотра файла — явное благо, и в винду не завезли ровно по одной причине — пользователь привык к дубль-клику. Иногда есть ошибочные решения, принятые на более ранних этапах (и в этих наших линуксах тоже, ага), от которых очень сложно избавиться.
Это в корп-секторе, да и то мало кто заморачивается.
Когда наша контора переходила с XP на Windows 7, я участвовал в процессе и попытался внедрить AppLocker. Очень скоро User Help Desk захлебнулась в обращениях вроде «Я в гостинице с ноутбуком, мне надо запустить католог запчастей с сидирома, а система не даёт, что делать?», и в конце концов мы его отключили.
Ну, собственно, я об этом и говорил. Крупные конторы иногда приходят к желанию навести порядок, не все, не всегда, но иногда бывает. Предположим, таких процентов 10. Те, кто «заморочился», на определенном этапе приходят к пониманию, что у порядка есть цена, которую они либо готовы платить, либо «выключают эту хрень нафиг». Тех, кто готов вкладываться в поддержание своего порядка, предположительно, примерно 10 процентов от тех, кто эту возню в принципе начинал. Итого, оценочно 1% от корп-сектора какую-то модель безопасности имеет, остальные кладут болт. «В домашних условиях» и «модель безопасности» — это два выражения, которые противопоказано использовать внутри одного предложения.
В Windows-системах «исполнимость» файлов как таковая определяется его расширением
…
В nix-системах «исполнимость» файла определяется правами на него и не существует в отрыве от ФС.
Не совсем так. Для начала, расширение в Windows не определяет «исполнимость» вообще — она лишь сигнализирует shell, что данный файл является исполняемым. Запустить на исполнение файл с расширением, отличным от .exe (или вообще не имеющий расширения) вполне можно — напрямую через WinAPI CreateProcess. Некоторые инсталляторы в процессе работы запускают дочерние процесс из файлов с расширением .tmp, например.
Продолжая дискуссию по поводу прав — разница в механизме прав запуска файла между Windows (с NTFS) и *nix мне всё же представляется не такой уж большой. В NTFS, как уже заметили, тоже есть отдельные права на чтение и запуск. То, что в Windows для запуска надо иметь на файле не только Execute, но и Read, а в *nix достаточно только Execute, по-моему, можно считать не сильно принципиальной архитектурной тонкостью. (Кстати, «Read and Execute» в Windows — не право как таковое, а удобный стандартный набор атомарных прав, существующий лишь на уровне shell. Да к тому же ещё и избыточный для запуска файла).
Подытоживая, получаем, что основная разница между системами находится на уровне их shell, ибо это именно они решают, пытаться запустить файл, чьё имя введено в качестве команды, или нет. В *nix системах, видимо, shell смотрит на наличие права «x», а в Windows — на расширение.
Подытоживая, получаем, что основная разница между системами находится на уровне их shellда
В *nix системах, видимо, shell смотрит на наличие права «x», а в Windows — на расширениеВыше был ответ, что нет. В nix-шеллах принципиально 2 разных действия: запустить и посмотреть. Двойной клик делает «посмотреть», а чтобы запустить, нужны приседания. Зато случайно не запустишь трояна (будь он хоть бинарником, хоть py-скриптом).
Я не доктор по линуксовым GUI, но не удивлюсь, если это поведение вообще задаётся в каком-нибудь конфигурационном файле.
Я не доктор по линуксовым GUI, но не удивлюсь, если это поведение вообще задаётся в каком-нибудь конфигурационном файле.
Лет 10 назад это было бы правдой. Сейчас уже нет. Единственные файлы, в которых можно определить это поведение на данный момент — исходники выбранного вами GUI.
Да и, собственно, наприседаетесь вы с объединением механизмов открытия и запуска в один дубль-клик. Они очень сильно по-разному работают на уровне нижележащей системы. «Авторасстановка звезд в порядке, позволяющем запустить произвольный файл по клику» — достаточно нетривиальная задача.
Для начала, расширение в Windows не определяет «исполнимость» вообще — она лишь сигнализирует shell, что данный файл является исполняемым.
Кхм. Если учитывать, что shell — это ровно та штатная штука, которая рулит процессами, определяет, кого запускать, а кого — не надо и собственно единственная штатная запускалка файлов… В чем разница «Windows определяет запускаемость файла по расширению» и «Windows-Shell определяет запускаемость файла по расширению»? Windows-shell — это компонент Windows, который служит для управления процессами, т.е. поведение Windows относительно запуска файлов — это ровно поведение shell'а.
Запустить на исполнение файл с расширением, отличным от .exe (или вообще не имеющий расширения) вполне можно — напрямую через WinAPI CreateProcess.
Кхм, а вы мне покажете, как это сделать, не запустив перед этим исполняемый файл с нужным расширением, содержащий инструкции «потыкать в WinAPI»?
Некоторые инсталляторы в процессе работы запускают дочерние процесс из файлов с расширением .tmp, например.
Некоторые инсталляторы — это программы, запускаемые файлы которых сами по себе имеют соответствующие расширения, которые позволяют этим инсталляторам запускаться оболочкой. А уж что происходит внутри вашей программы и что и каким образом вы из нее запускаете — это системе уже примерно ортогонально. Ваша программа вполне может быть шеллом сама по себе, посмотрите на cygwin.
В NTFS, как уже заметили, тоже есть отдельные права на чтение и запуск.
В NTFS есть отдельные права на чтение, и отдельные права на чтение-и-запуск. Атомарное право на запуск в NTFS не существует. Собственно, к чему это ведет:
1. Вы не можете дать пользователю право запускать скрипт, не дав возможности посмотреть в содержимое скрипта. Может быть нужно, например, если скрипт содержит какие-то специфические данные типа паролей на доступ к каким-то ресурсам, которые пользователю знать не положено. Почему бы и нет. И, на всякий случай, «импортировать чувствительные данные из другого файла в процессе работы» — не помогает, на импортируемые файлы у пользователя тоже должны быть права на чтение.
2. Вы не можете дать пользователю права на запуск, не дав ему права скопировать запускаемую программу. Уже меньше похоже на мелочь, например?
То, что в Windows для запуска надо иметь на файле не только Execute, но и Read, а в *nix достаточно только Execute, по-моему, можно считать не сильно принципиальной архитектурной тонкостью.
Чуть выше привел два примера, когда отдельный Execute бывает удобен. Если добавить к этому наличие sticky-битов, получаем достаточно мощный механизм, аналогов которому Windows-shell не предоставляет.
Кстати, «Read and Execute» в Windows — не право как таковое, а удобный стандартный набор атомарных прав
То, что это набор прав и в явную два атрибута в файловой системе — это я знаю. И что «Read&Exec» — это пара прав, а не одно право — это я тоже знаю. Но вот с «атомарностью» буду спорить. В паре Read&Exec exec без read не работает — странная какая-то атомарность.
В *nix системах, видимо, shell смотрит на наличие права «x», а в Windows — на расширение.
В *nix-системах shell смотрит на то, что от него хочет пользователь. Если пользователь требует выполнить указанный файл, проверят права на исполнение, и, если они достаточны, выполняет. Если пользователь просит открыть файл другой программой (видеоплейером, просмотрщиком изображений, редактором и т.д. и т.п.) — запускает другую программу, если у пользователя достаточно прав для ее запуска, и скармливает ей на вход указанный файл.
В Windows-системах эти два понятия размыты по двум разным механизмам — собственно запускалкой shell'а и механизмом файловых соответствий. Причем размыты до неразличимости.
Что такое, собственно, механизм файловых соответствий? Это достаточно тупая и прямолинейная штука, которая смотрит в расширение файла и, в зависимости от букв, которые в нем видит, запускает другую программу, которой на вход отдает указанный вами файл. Понимаете, такая вполне удобная штука — открываете вы один файл, а при этом на автомате запускаете вы совершенно другой.
Очень удобная штука! Позволяет вместо того, чтобы открыть просмотрщик фотографий и через его временами очень специфическое файловое меню искать нужную вам фотографию, просто тупо дубль-кликнуть в нужную, «а дальше оно само».
В том, собственно, и разница между «открытием файла» и «запуском файла». При запуске запускается сам файл, а при открытии — запускается совершенно другой файл, который уже открывает ваш исходный.
Ну вот, собственно, вот эти два процесса в *nix-системах — это явным образом два разных механизма. Во всех линуксовых shell'ах, включая графические оболочки и IDE явный запуск файла на исполнение — это явный запуск файла на исполнение. А «файловых ассоциаций» либо вообще нет как таковых (верно для консольных оболочек, терминалов и т.д.), либо они являются отдельной операцией.
Дубль-клик по файлу в файловом менеджере в линуксе всегда означает именно открытие файла, а не его исполнение.
Посмотрим на Windows? Дубль клик всегда означает передачу файла механизму файловых ассоциаций. Всегда, без исключений. И если этот механизм не нашел никакого соответствия, то файл отдается на механизм исполнения, который контроллится по файловому расширению. Хорошо ли это? Если честно, откуда оно растет, и как так получилось — примерно понятно. А вот «хорошо» — это конкретно не про этот случай. Это ужасно с концептуальной точки зрения, это ужасно реализовано, это постоянно ломается и выглядит как лютый писец.
В NTFS есть отдельные права на чтение, и отдельные права на чтение-и-запуск. Атомарное право на запуск в NTFS не существует.
Ну как это не существует? Именно атомарное и именно существует. Название в GUI — «Traverse folder/Execute file». Бит 5 в поле AccessMask структуры ACE, если не вру. Другое дело, что наличия одного этого права недостаточно для того, чтобы иметь возможность запускать файл, надо ещё иметь как минимум атомарные права «Read data» и «Read extended attributes». Но это всё — разные атомарные права.
И что «Read&Exec» — это пара прав, а не одно право — это я тоже знаю.
Не пара, а целых пять :-)
Но вот с «атомарностью» буду спорить. В паре Read&Exec exec без read не работает — странная какая-то атомарность.
У Майкрософт такой подход встречается и в других местах. Например, у шаблонов сертификатов есть атомарное право «Enroll», которое необходимо, чтобы иметь возможность отправить запрос на выпуск сертификата на основании данного шаблона. Но в одиночку это право не работает, надо иметь ещё и право на чтение шаблона.
В принципе в этом можно углядеть свою логику. Если у вас есть ключ от квартиры, а в подъезде дверь запирается, то чтобы попасть в квартиру, вам всё равно ещё нужен ключ от подъезда.
С остальным в целом согласен.
Ну как это не существует? Именно атомарное и именно существует. Название в GUI — «Traverse folder/Execute file». Бит 5 в поле AccessMask структуры ACE, если не вру. Другое дело, что наличия одного этого права недостаточно для того, чтобы иметь возможность запускать файл, надо ещё иметь как минимум атомарные права «Read data» и «Read extended attributes». Но это всё — разные атомарные права.
Разные — да, даже не оспаривал. Атомарные — нет. Атомарность прав доступа в математическом смысле означает «необходимость и достаточность». Т.е. атомарные права самодостаточны, т.е. не требуют наличия некоторой комбинации других прав для однозначного понимания, исполнимо ли соответствующее право, а также не зависят от соседних прав. С тем, что «Чтение» или «Запись» атомарны я готов согласиться (с оговоркой, что NTFS-права, кроме того, обладают механизмом наследования, т.е. атомарны они лишь в разрезе своего уровня вложенности). А вот об атомарности «Исполнения» говорить не приходится, т.к. работает оно исключительно при наличии права на «Чтение». Т.е. по наличию единицы в 5-м бите в поле AccessMask структуры ACE вы не можете однозначно определить, будет ли оно исполняться, вам придется посмотреть в один из соседних битов, соответствующий праву на чтение.
Не пара, а целых пять :-)
Нивапрос ваще, бро! Все еще хуже, чем я думал)))
У Майкрософт такой подход встречается и в других местах. Например, у шаблонов сертификатов есть атомарное право «Enroll», которое необходимо, чтобы иметь возможность отправить запрос на выпуск сертификата на основании данного шаблона. Но в одиночку это право не работает, надо иметь ещё и право на чтение шаблона.
Если в одиночку право не работает, оно неатомарно. Подберите другой термин, и все будет ок.
В принципе в этом можно углядеть свою логику. Если у вас есть ключ от квартиры, а в подъезде дверь запирается, то чтобы попасть в квартиру, вам всё равно ещё нужен ключ от подъезда.
В принципе, если в подъезде дверь запирается, наличие ключа от квартиры не дает вам атомарного права входа в квартиру. Все же элементарно. А вот наличие ключа от подъезда дает вам атомарное право входа в подъезд — это да.
Или у вас другое понятие атомарности? Тогда подскажите, чем атомарные права от неатомарных отличаются.
Просто та же википедия выдает такую штуку:
«Атомарная (атом от греч. atomos — неделимое) операция — операция, которая либо выполняется целиком, либо не выполняется вовсе; операция, которая не может быть частично выполнена и частично не выполнена.» В случае с правами, очевидно, атомарным может считаться право, которое «не может быть частично выполнена и частично не выполнена». Единичка в бите «исполнение» и отсутствие таковой в бите «чтение» означает именно ситуацию «частично право есть», т.е. оно как будто бы и есть, и при этом ни разу не выполняется. Налицо нарушение принципа атомарности.
этого набора прав достаточно для запуска приложения (без read data):
Traverse Folder/Execute File
Магия какая-то, неатомарная какая-то)))
Магия какая-то, неатомарная какая-то)))
Честно говоря, я не добивался возможности запуска файла только при установленном одном разрешении. Но у вас термин «атомарность» явно используется в кач-ве «абракадабра», магии. Цель разделения разрешений — обеспечение гибкости в предоставлении доступов. NTFS это позволяет, в том числе обеспечить права на запуск файла без его чтения. Хотя именно этот кейс, кроме как продемонстрировать вам возможность эмуляции rwx, никакого практического смысла не нес.
Но у вас термин «атомарность» явно используется в кач-ве «абракадабра», магии.
Не, у меня «атомарность» используется в значении, соответствующем определению термина. Не знал, что можно использовать как-то иначе.
Атомарность — это определение минимальной неделимой осмысленной единицы. В контексте прав, для того, чтобы право считалось атомарным, необходимо, чтобы:
— право было единичным (т.е. устанавливалось одной галочкой за одно действие);
— право было самодостаточным (т.е. было применимо вне зависимости от набора окружающих прав).
Для того, что вы пытаетесь назвать атомарным, есть другое определение. Погуглите «комплементарность». Вот право на чтение у вас атомарно — оно работает само по себе. Право на исполнение — комплементарно относительно прав на чтение (т.е. оно дополняет право на чтение, и не имеет смысла в отрыве от оного).
Расширяйте лексикон, в общем.
Вы озвучили некие «свои в себе» термины (относительно конкретной области), после чего сравниваете существующие возможности NTFS с этими своими определениями и удивляетесь, что она им не соответсвует. Тут уж, извините, лексикон не поможет — либо исходно договаривайтесь о терминах (с отсылкой на требования), либо не используйте собственные прочтения терминов.
Ну итить твою маковку, золотая рыбка. Надеюсь, происхождение понятия атомарности из логики вы отрицать не будете? Вот вам строгое определение логической атомарности:
«АТОМАРНЫЙ ФАКТ — одно из основных понятий логического атомизма, обозначающее факт, не разложимый на составные факты, состоящий из сочетаний вещей и предметов мысли. Атомарные факты полагаются независимыми друг от друга, так что из существования (несуществования) одного атомарного факта нельзя сделать вывод о существовании (несуществовании) др. Таким образом, отрицается взаимосвязь, единство мира, а процесс познания практически ограничивается описанием атомарного факта. Это метафизическое понятие возникло в результате перенесения на явления внешнего мира некоторых свойств «атомарных» (элементарных) предложений, играющих важную роль в математической логике. По своему существу понятие «Атомарный факт» родственно «элементам мира» Маха.»
Мне кажется, суть атомарности неверно истолкована не мной…
Прочтите внимательно, вдумчиво. Обратите внимание: «не разложимый на составные факты». Отрицать то, что право на «Чтение и Исполнение» таки состоит из прав на чтение и права на исполнение, надеюсь, не будете? Дальше дочитайте до «Атомарные факты полагаются независимыми друг от друга» и признайте, что право на исполнение никак не получается не зависящим от права на чтение.
Л — Логика. Есть такая наука.
«АТОМАРНЫЙ ФАКТ — одно из основных понятий логического атомизма, обозначающее факт, не разложимый на составные факты, состоящий из сочетаний вещей и предметов мысли. Атомарные факты полагаются независимыми друг от друга, так что из существования (несуществования) одного атомарного факта нельзя сделать вывод о существовании (несуществовании) др. Таким образом, отрицается взаимосвязь, единство мира, а процесс познания практически ограничивается описанием атомарного факта. Это метафизическое понятие возникло в результате перенесения на явления внешнего мира некоторых свойств «атомарных» (элементарных) предложений, играющих важную роль в математической логике. По своему существу понятие «Атомарный факт» родственно «элементам мира» Маха.»
Мне кажется, суть атомарности неверно истолкована не мной…
Прочтите внимательно, вдумчиво. Обратите внимание: «не разложимый на составные факты». Отрицать то, что право на «Чтение и Исполнение» таки состоит из прав на чтение и права на исполнение, надеюсь, не будете? Дальше дочитайте до «Атомарные факты полагаются независимыми друг от друга» и признайте, что право на исполнение никак не получается не зависящим от права на чтение.
Л — Логика. Есть такая наука.
UFO just landed and posted this here
Разные — да, даже не оспаривал. Атомарные — нет. Атомарность прав доступа в математическом смысле означает «необходимость и достаточность».
Ну я вот как-то затруднюсь назвать авторитетный источник, в котором даётся строгое математическое определение понятия «атомарности» применительно к правам доступа. Я этот термин использовал в смысле «нельзя разложить на более мелкие права».
Т.е. атомарные права самодостаточны, т.е. не требуют наличия некоторой комбинации других прав для однозначного понимания, исполнимо ли соответствующее право, а также не зависят от соседних прав.
Самодостаточность — дело такое… Все права требуют для своей работы выполнения каких-то внешних условий. «Атомарное» право запуска в Линуксе требует, чтобы в опциях монтирования не стояло noexec. А возможность записи требует, чтобы том не был read-only. Так что они тоже не вполне «самодостаточные», и возвращаясь к NTFS можно сказать, что «в NTFS при наличии права чтения файла пользователю так же можно дать право запуска».
С тем, что «Чтение» или «Запись» атомарны я готов согласиться
И напрасно, потому что ни то, ни другое в NTFS не атомарно, какое определение ни возьми :-) Чтений есть аж четыре — чтение данных, атрибутов, расширенных атрибутов и разрешений. А запись различается на запись данных, дозапись данных, запись атрибутов, расширенных атрибутов, запись разрешений (DACL и SACL) и установку владельца.
Кстати, могу привести интересную иллюстрацию сложностей с правами в Windows — правда, не в NTFS, а в Active Directory. В Windows Server 2008 была такая проблема с шаблонами сертификатов. Если у тебя есть право на изменение разрешений шаблона, но нет права на установку владельца, то ты не можешь и разрешения поменять: консоль выдаёт ошибку, что у тебя нет права на изменение владельца, хотя ты его не менял. Это был косяк самой консоли: при попытке изменения разрешений она пыталась записать не только изменённый DACL, а весь Security Descriptor объекта, включающий DACL, SACL и Owner, что AD воспринимала как попытку установки владельца и отказывала в выполнении. Для решения проблемы я писал отдельный скрипт, который устанавливал DACL — кажется, через WMI.
Ну я вот как-то затруднюсь назвать авторитетный источник, в котором даётся строгое математическое определение понятия «атомарности» применительно к правам доступа. Я этот термин использовал в смысле «нельзя разложить на более мелкие права».
Атомарность предполагает сущность. Т.е. минимальный неделимый существующий элемент. Если мы говорим о правах доступа, стоит вспомнить, что каждое существенное право доступа — это право на выполнение какой-то операции. Галочка «Execute» никакого права сама по себе не дает, т.е. не обеспечивает условия существенности. В отрыве от права на чтение условие исполнимости файла не соблюдается. Т.е. галочка execute существует в качестве правила, дополняющего/расширяющего право на чтение. Для этого поведения существует другое, более корректное определение — комплементарность.
Право на чтение — атомарно. Право на исполнение в NTFS — комплементарно относительно права на чтение.
Самодостаточность — дело такое… Все права требуют для своей работы выполнения каких-то внешних условий. «Атомарное» право запуска в Линуксе требует, чтобы в опциях монтирования не стояло noexec. А возможность записи требует, чтобы том не был read-only. Так что они тоже не вполне «самодостаточные», и возвращаясь к NTFS можно сказать, что «в NTFS при наличии права чтения файла пользователю так же можно дать право запуска».
Один нюанс. NTFS-право на исполнение несамодостаточно прямо в контексте NTFS-прав. Т.е. оно не существует (не реализуемо) в отрыве от NTFS-права на чтение. Даже галочка называется «Чтение и исполнение» — вас в названии ничего не смущает. А линуксовые rwx — права гарантируют, что на уровне rwx-прав каждое право самодостаточно, реализуемо и не влияет на соседей. Поэтому они атомарны. Иначе мы дойдем до того, что «ничто не атомарно, даже небо, даже Аллах».
Все права требуют для своей работы выполнения каких-то внешних условий.
Это внешние условия. Не имеющие никакого отношения к атомарности прав внутри системы прав. Атомарность в принципе применима исключительно в рамках какой-то системы, она не существует в виде всеобъемлющего понятия. В конце концов «атом» в значении «неделимый» был корректен ровно до тех пор, пока мы не узнали, что существуют более мелкие частицы. Но в системе «молекулы состоят из атомов» атом достаточно атомарен.
«Атомарное» право запуска в Линуксе требует, чтобы в опциях монтирования не стояло noexec.
Плохой пример, например. Вот вообще неудачный. «noexec» — это правило монтирования, запрещающее драйверу файловой системы возвращать признак исполнимости. Т.е. noexec игнорирует это самое право, и любой rwx, -wx, r-x и даже --x файловая система отобразит для ядра как rw-, -w-, r-- и — соответственно. Никаких условий «если x есть, но стоит noexec» нет, просто нету никакого x.
А возможность записи требует, чтобы том не был read-only.
Не смешивайте атрибуты файловой системы с исполнимостью полученных разрешений. Повторю еще раз: «Read&Execute» неатомарен прямо на уровне прав NTFS, вне зависимости от других уровней реализации этих прав. Собственно, физическое повреждение диска точно так же может оказаться причиной, почему exec не сработал — это не повод все мешать в одну кучу.
Собственно, исходя из вашей же вот этой странный логики «а мы все смешаем в кучу», вы еще более неправы, утверждая, что NTFS-права атомарны. Вы же только что доказали, что ничего не атомарно, а термин бессмысленный.
Так что они тоже не вполне «самодостаточные», и возвращаясь к NTFS можно сказать, что «в NTFS при наличии права чтения файла пользователю так же можно дать право запуска».
Вот именно: при наличии права на чтение можно дать право исполнения. Это называется «комплементарность». Сравните «можно дать право на чтение» (атомарность) с «при наличии права на чтение, можно дать право на исполнение» (комплементарность), найдите разницу.
И напрасно, потому что ни то, ни другое в NTFS не атомарно, какое определение ни возьми :-) Чтений есть аж четыре — чтение данных, атрибутов, расширенных атрибутов и разрешений. А запись различается на запись данных, дозапись данных, запись атрибутов, расширенных атрибутов, запись разрешений (DACL и SACL) и установку владельца.
Жуть какая. Ну вот, собственно, попробуем разобраться в «приколе». Итого, есть 4 права чтения, каждое из которых настолько уникально, что даже имеет собственное название. Хранится оно, скорее всего, в виде битовой маски, хранящий набор атомарных атрибутов (обратите внимание на слово «атрибутов», при том, что я не совсем уверен в атомарности этого атрибута, но вот они, скорее всего, атомарны). Т.е., упрощая, мы можем для демонстрации записать это дело вот как 0010 или 1111 — т.е. определив первый разряд как «чтение данных», второй «чтение атрибутов» и далее «чтение расширенных атрибутов» и «чтение разрешений» соответственно. Итак, что такое атомарность в разрезе атрибутов файловой системы: это минимальная комбинация нолей и единичек, существующая как единая сущность (в контексте работы с атрибутами важным признаком будет возможность установки этого самого атрибута). Если каждый атрибут может устанавливаться отдельно (т.е. у вас есть отдельная галочка на «чтение данных», отдельная — на «чтение атрибутов» и т.д.) — то это 4 атомарных атрибута. Если, допустим, у вас 2 атрибута в файловой системе, которые включаются-выключаются одной галочкой — это «комплементарная пара». Если для того, чтобы воткнуть единичку в позицию «чтение расширенных атрибутов» вам сначала нужно воткнуть единичку в поле «чтение атрибутов», но не наоборот, то «чтение атрибутов» — атомарный атрибут, а «чтение расширенных атрибутов» — комплементарный атрибут относительно «чтения атрибутов».
Теперь переходим на уровень выше. У вас есть список прав, которые определяют список доступных вам действий над файлами. Они каким-то образом «маппятся» на атрибуты ФС, не всегда 1-в-1. Собственно, если есть отдельные права «чтение данных», «чтение атрибутов», «чтение расширенных атрибутов» и «чтение разрешений» — они, скорее всего, атомарны с одним нюансом: если, допустим, «чтение расширенных атрибутов» требует наличие «чтения атрибутов», то оно не атомарно. Элементарно даже потому, что вы можете явным образом отобрать у пользователя «чтение атрибутов», а у него от этого перестанет работать «чтение расширенных атрибутов». Ну какая же это атомарность, я вас умоляю.
В конце концов, вся суть возни с «атомарностью» в том, что атомарность права гарантирует, что при вкл/выкл этого права вы гарантировано получаете вкл/выкл именно этого права и отсутствие побочных эффектов на другие права.
Если при «выкл» права на чтение вы лишаетесь еще и права на исполнение — это называется «комплементарность». Если же при явном выключении «чтения» вы все еще можете читать файл, потому что рядом еще что-то разрешает — это называется «хрень какая вместо набора прав».
Кстати, могу привести интересную иллюстрацию сложностей с правами в Windows — правда, не в NTFS, а в Active Directory.
Ну, в общем и целом, я об этом и говорю: ntfs-права в ряде случаев комплементарны, и вообще больше склоняются в комплементарную степь. Вы поймите, я не утверждаю, что не-атомарность прав — это плохо-плохо и ужас-ужас. Собственно, nix-овые rwx гарантировано атомарны. С точки зрения математики — это круто. С точки зрения реального применения — вся эта математическая красота ставит нас в положение жующего оленя как только бизнес требует настройки «гибких разрешений». И чтобы это как-то решить, поверх собственно rwx-прав существует еще и apparmor/selinux, которые комплементарны по своей сути, т.к. являются комплементарным дополнением к rwx.
Вообще не понимаю, чего вы за атомарность уцепились. Ну неатомарны права, и что? Плохо, что ли? С математической точки зрения значительная часть windows-прав неатомарна, очень много комплементарных наборов и взаимозависящих пар. Но это ведь от решения реальных насущных проблем. Посмотрите в соседний лагерь, думаете там получилось решить эту проблему изящно-атомарным подходом? Да хрен-то там, там набору rwx-прав всю эту сложность накрутили сбоку отдельным инструментом, создав комплементарный набор на уровне инструментов.
Вообще не понимаю, чего вы за атомарность уцепились. Ну неатомарны права, и чтоИспользование вами в случае разрешений ФС понятия «атомарность» предполагает, что вы выделили некие «атомарные операции» ФС в контексте разрешений. Субъективно я вас понимаю, но использование этого термина должно подразумевать, что те «атомарные» права, к-рые вы предоставляете, выражают «атомарные» операции ФС. То есть «атомарность» прав без деталей реализации ФС смысла не имеет.
Использование (не только мной) понятия «атомарность» предполагает следование и непротиворечие смыслу этого понятия. Атомарность — это философская категория, существующая в контексте логики, как поддисциплины философии. Означает она, в первую очерень, (прямо из самого слова «амтос» — гр. «неделимый») — неделимость сущности, описываемой понятием «атомарная». «Read&Execute» при явном наличии права «Read» прозрачно намекает нам, что право — составное. Т.е. из него можно выделить право на чтение, что явным образом противоречит понятию атомарности.
Чуть выше я привел достаточно четкую официально принятую формулировку логического понятия «атомарный факт». На всякий случай, повторю:
Т.е. официальный список требований к «атомарности» с точки зрения логики:
1. Неделимость
2. Изолированность
3. Независимость
4. Самодостаточность
И это — прямое понятие математической логики. Если у вас какое-то свое представление — срочно меняйте.
Я достаточно четко разделяю:
а) атрибуты ФС, которое суть есть набор именованных нолей и единичек в битовой маске
б) права файловой системы, которые выражаются (не всегда «в лоб») в набор атрибутов ФС
в) операции, разрешаемые этими правами.
Каждый элемент каждой из этих трех частей может быть, а может и не быть атомарным (равно как и, например, комплементарным). В контексте атрибутов ФС каждая единичка/нолик в битовой маске, которую вы можете установить независимо от других, сама по себе атомарна. Но! Атомарность атрибутов ФС вообще не означает атомарности прав, которые этими самыми атрибутами выражаются.
Каждое право доступа атомарно в том случае, если вы явно можете установить его отдельно одной операцией. Если какое-то другое право из доступного набора препятствует исполнению этого права, право не атомарно — это математическая логика.
Совершенно не обязательно, например. Набор прав определяется вами (точнее, создателем этого набора прав). Создатели rwx решили, что каждое из их прав атомарно, и подгоняют детали реализации исполнения этих прав под условие, что право атомарно. Создатели NTFS решили, что исполнение без чтения смысла не имеет, и потому изначально сделали комплементарную пару (официально так называется, и да, является антонимом к атомарности) Read&Execute, не подгоняя окружающую реальность к атомарности.
Собственно, при чем тут реализация? Тут вопрос в чем. Если есть спецификация, определяющая набор прав ФС и то, как эти права работают, и при этом есть реализация ФС, которая этой спецификации противоречит, то это просто забагованная реализация. Это не «детали реализации» получается, а явный баг.
Чуть выше я привел достаточно четкую официально принятую формулировку логического понятия «атомарный факт». На всякий случай, повторю:
АТОМАРНЫЙ ФАКТ — одно из основных понятий логического атомизма, обозначающее факт, не разложимый на составные факты, состоящий из сочетаний вещей и предметов мысли. Атомарные факты полагаются независимыми друг от друга, так что из существования (несуществования) одного атомарного факта нельзя сделать вывод о существовании (несуществовании) др. Таким образом, отрицается взаимосвязь, единство мира, а процесс познания практически ограничивается описанием атомарного факта. Это метафизическое понятие возникло в результате перенесения на явления внешнего мира некоторых свойств «атомарных» (элементарных) предложений, играющих важную роль в математической логике. По своему существу понятие «Атомарный факт» родственно «элементам мира» Маха.
Т.е. официальный список требований к «атомарности» с точки зрения логики:
1. Неделимость
2. Изолированность
3. Независимость
4. Самодостаточность
И это — прямое понятие математической логики. Если у вас какое-то свое представление — срочно меняйте.
Использование вами в случае разрешений ФС понятия «атомарность» предполагает, что вы выделили некие «атомарные операции» ФС в контексте разрешений.
Я достаточно четко разделяю:
а) атрибуты ФС, которое суть есть набор именованных нолей и единичек в битовой маске
б) права файловой системы, которые выражаются (не всегда «в лоб») в набор атрибутов ФС
в) операции, разрешаемые этими правами.
Каждый элемент каждой из этих трех частей может быть, а может и не быть атомарным (равно как и, например, комплементарным). В контексте атрибутов ФС каждая единичка/нолик в битовой маске, которую вы можете установить независимо от других, сама по себе атомарна. Но! Атомарность атрибутов ФС вообще не означает атомарности прав, которые этими самыми атрибутами выражаются.
Каждое право доступа атомарно в том случае, если вы явно можете установить его отдельно одной операцией. Если какое-то другое право из доступного набора препятствует исполнению этого права, право не атомарно — это математическая логика.
Субъективно я вас понимаю, но использование этого термина должно подразумевать, что те «атомарные» права, к-рые вы предоставляете, выражают «атомарные» операции ФС.
Совершенно не обязательно, например. Набор прав определяется вами (точнее, создателем этого набора прав). Создатели rwx решили, что каждое из их прав атомарно, и подгоняют детали реализации исполнения этих прав под условие, что право атомарно. Создатели NTFS решили, что исполнение без чтения смысла не имеет, и потому изначально сделали комплементарную пару (официально так называется, и да, является антонимом к атомарности) Read&Execute, не подгоняя окружающую реальность к атомарности.
То есть «атомарность» прав без деталей реализации ФС смысла не имеет.
Собственно, при чем тут реализация? Тут вопрос в чем. Если есть спецификация, определяющая набор прав ФС и то, как эти права работают, и при этом есть реализация ФС, которая этой спецификации противоречит, то это просто забагованная реализация. Это не «детали реализации» получается, а явный баг.
Вот термин «атомарность» в рамках требований к модели ACID:
Как вы предполагаете применить это определение к правам в ФС? Или вы считаете, что термин из древнегреческой философской мысли подходит лучше?
Атомарность гарантирует, что никакая транзакция не будет зафиксирована в системе частично. Будут либо выполнены все её подоперации, либо не выполнено ни одной.
Как вы предполагаете применить это определение к правам в ФС? Или вы считаете, что термин из древнегреческой философской мысли подходит лучше?
Или вы считаете, что термин из древнегреческой философской мысли подходит лучше?
А вы искренне считаете, что что-то другое, отличное от первоисточника определения, подходит на эту роль лучше? Ну давайте ближе к «правам» сходим: аббревиатура ABAC вам что-то говорит? Подскажу, это концепция, которую и реализуют NTFS-права. Attribute-Based Acess Control, в противовес RBAC (Role-Based Access Contorl). Можете сходить к майкам и убедиться, что NTFS-права — это именно ABAC. А я пока дам вам вот эту ссылку: en.wikipedia.org/wiki/Attribute-based_access_control.
Заодно загляну в текст и найду там одно любопытное утверждение: «Attribute values can be set-valued or atomic-valued. Set-valued attributes contain more than one atomic value.»
Для удобства переведу: «Значения атрибутов могут состоять из множественного значени или быть атомарными значениями. Множественные атрибуты содержат более одного атомарного значения». Это та бумажка, которая описывает ABAC, т.е. модель, которая реализована в NT-системах в качестве NTFS-атрибутов/NTFS-прав. И там, едрить вашу маковку, прямо написано, что «множественные атрибуты состоят из нескольких атомарных», т.е. «атомарные» тем от множественных и отличаются, что они из одного атомарного значения состоят! Прямо так и написано: " Atomic-valued attributes contain only one atomic value"
«Read&Execute» состоит из 2 атомарных значений! Посчитайте сами, Read — раз, Execute — два. Два больше одного, в формулировке прямо сказано, что более одного — не атомарные.
Смиритесь уже, Read&Execute НЕ атомарное.
Я вполне уверен в том, что нельзя пользоваться несогласованными или несуществующими терминами.
Вы привели ссылку на wiki, а не документацию MS. Но давайте пользоваться хотя бы такой терминологией:
Но, возможно, мы спорим вообще о разном. Вы упорно упоминаете комбинацию «Read&Execute», к-рая на самом деле является комбинацией нес-ких детальных разрешений. Я же вам пишу про те разрешения, комбинацией к-рых является злосчастный «Read&Execute»: «Чтение разрешений», «Чтение дополнительных атрибутов», «Чтение атрибутов» и т.д. (там их много больше 2х =) )
Эти дополнительные разрешения ( в терминологии Windows) являются «атомарными» — в том смысле, к-рый вы транслируете: они назначаются независимо и не имеют составных частей.
Замученный же вами «Read&Execute» не является неким разрешением — это (как и Full Control, Change, Read & Write) комбинации дополнительных прав. Вы можете увидеть эти дополнительные «атомарные» права в интерфейсе, если нажмете кнопку «Дополнительно» на вкладке «Безопасность». Вот они — «атомарные». Они явно дают определенные возможности (например, читать атрибуты, читать доп атрибуты и т.д.). Эти дополнительные разрешения удивительно полезны для сложных кейсов. Как, например, сделать так, чтобы пользователь не мог смотреть промежуточные папки, но могу исполнять файлы в конечной папке?
по вопросу выше (хоум-нехоум) — еще через часок ;)
Вы привели ссылку на wiki, а не документацию MS. Но давайте пользоваться хотя бы такой терминологией:
Attribute values can be set-valued or atomic-valued. Set-valued attributes contain more than one atomic value. Examples are role and project. Atomic-valued attributes contain only one atomic value.Вы упускаете тот простой момент, что в реализации MS разрешения «Траверс папок/Выполнение файлов» и «Содержание папки/Чтение данных» атомарные в соответствии с описанной выше терминологией: установка одного из них не приводит в установке другого, и наоборот.
А вы искренне считаете, что что-то другое, отличное от первоисточника определения, подходит на эту роль лучше?Вы явно не занимались технической документацией. Значение термина (кроме общепринятых в *данной* сфере) должно быть явно заявлено в документации. Пока вы не продемонстрируете термин «атомарность» в контексте «разрешения файловой системы», его применение будет являться натяжкой совы на глобус.
Но, возможно, мы спорим вообще о разном. Вы упорно упоминаете комбинацию «Read&Execute», к-рая на самом деле является комбинацией нес-ких детальных разрешений. Я же вам пишу про те разрешения, комбинацией к-рых является злосчастный «Read&Execute»: «Чтение разрешений», «Чтение дополнительных атрибутов», «Чтение атрибутов» и т.д. (там их много больше 2х =) )
Эти дополнительные разрешения ( в терминологии Windows) являются «атомарными» — в том смысле, к-рый вы транслируете: они назначаются независимо и не имеют составных частей.
Замученный же вами «Read&Execute» не является неким разрешением — это (как и Full Control, Change, Read & Write) комбинации дополнительных прав. Вы можете увидеть эти дополнительные «атомарные» права в интерфейсе, если нажмете кнопку «Дополнительно» на вкладке «Безопасность». Вот они — «атомарные». Они явно дают определенные возможности (например, читать атрибуты, читать доп атрибуты и т.д.). Эти дополнительные разрешения удивительно полезны для сложных кейсов. Как, например, сделать так, чтобы пользователь не мог смотреть промежуточные папки, но могу исполнять файлы в конечной папке?
Через rwx - никак
react-intro aleksey$ cd
~ aleksey$ mkdir demo
~ aleksey$ cd demo
demo aleksey$ mkdir child
demo aleksey$ cd child/
child aleksey$ vim doit.sh
child aleksey$ chmod +x doit.sh
child aleksey$ ./doit.sh
1
child aleksey$ cd ..
demo aleksey$ ls -la
total 0
drwxr-xr-x 3 aleksey staff 96 Jun 15 15:57 .
drwxr-xr-x+ 116 aleksey staff 3712 Jun 15 15:57 ..
drwxr-xr-x 3 aleksey staff 96 Jun 15 15:57 child
demo aleksey$ chmod 000 child/
demo aleksey$ ls -lh
total 0
d--------- 3 aleksey staff 96B Jun 15 15:57 child
demo aleksey$ ls child/
ls: : Permission denied
demo aleksey$ child/doit.sh
-bash: child/doit.sh: Permission denied
demo aleksey$ по вопросу выше (хоум-нехоум) — еще через часок ;)
Куча серьезных производителей софта клали на эти требования. Например гугл с хромом.
Не совсем так. Хром может ставиться как в профиль пользователя, так и в Program Files для всех пользователей. Если он устанавливается вторым способом, то, как и положено, хранит все свои данные отдельно, в профиле пользователя. Первый вариант используется для возможности установки пользователями, не имеющими административных прав (как по мне, вредная опция).
В Windows бывает софт, поддерживающий установку только для всех пользователей, только для одного пользователя, и поддерживающий оба варианта. В зависимости от этого меняется место установки. В организациях, где есть IT, обычно отдают предпочтение установке per machine (для всех пользователей).
По Линуксу ладно, я не слишком большой специалист, хотя системы, где пользователи не могли запускать из своей домашней директории, точно видел.
По хорошему должно быть только 2 типа каталогов — в которые можно писать, но из которых нельзя запускать, и из которых можно запускать, но нельзя писать (простому пользователю).
Абсолютно верно.
Они всегда пишут только в своей директорией, а это Windows категорически не нравится.
Это и Линуксу не нравится. Попробуйте без sudo записать в /lib, например.
Хотя казалось бы что это самое безопасное поведение.
Это отвратительное поведение, приводящее к безбожному замусориванию системы и трудно разрешимым проблемам управления инсталляцией. Как сисадмин, я люто ненавижу такие программы. Софт должен лежать в одном месте, а все данные, с которыми он работает — в другом. Microsoft даже отдельный подмеханизм в UAC изобрела для борьбы с такими программами.
cделает файлы некоторых расширений открываемыми собой
И правильно сделает. Ведь пользователю нужен редактор, чтобы редактировать изображения. Для этого ассоциации расширений с софтом и придумали.
Лучшее, что я видел, приложение состоящее из одной exe. Оно просто запускается и работает.
И при этом не удобное для пользователя:
— Где оно там лежит — не понятно. Что, сложно ярлык на декстоп положить?
— Файлы не открывает. Мне что нужно сначала открывать прогу, а потом в неё выбирать файл? Не требует через командную строку файл для открытия задавать и на том спасибо.
И это еще цветочки. А вот, если приложение написано на ассемблере! Тогда настает Адъ и Армагедон. :D
Все антивирусы начинают кричать одновременно "зловред, зловред". ВирусТотал подтверждает все. А все браузеры блокируют сайт.
И начинается большое приключение под названием "False Positive Submission".
Я в эту игру играю уже 20 лет — сайт FlatAssembler и Fresh IDE периодически подпадают под санкции. И ни единого раза не было чтобы действительно был зловред.
Как раз сейчас пытаюсь вычистить Fresh.exe v2.7.0 на VirusTotal — было 26/72, сейчас 11/72 — после около месяца переписки.
А когда выйдет примерно v2.7.1, все начнется сначала. Потому что большинство AV не исправляют код, а тупо вписывают хеш файла в белый список.
Отчасти проблему с большинством недоантивирусов на вирустотале для программ на асме можно попробовать решить подогнав заголовки (optional_header и section_header) под значения, которые оставляет компоновщик из msvs (или на крайний случай из llvm), а также оформив точку входа (EP), как это делает сишный компилер оттуда же.
А именно:
- optional_header: Linker Version, OS Version, Size Of Stack Reserve, Size Of Stack Commit, Size Of Heap Reserve, Size Of Heap Commit;
- секции: имена секций, атрибуты (особенно секция кода БЕЗ разрешённой записи — это прям алярм-ахтунг)
- точка входа: наличие какого-нибудь пролога (элементарно push ebp; mov ebp, esp; push любой non-volatile регистр).
Это из того, что увидел во fresh.exe.
Ну, не знаю… Я тоже думал об этом, но мне всегда казалось, что такое решение как-то является неморальным что ли.
В конце концов, пытаться понравится AV по моему безнадежная затея. И если сегодня прогнусь, завтра будет что-то другое. Прогнувшись однажды, придется прогибаться всегда.
Это совсем не попытка понравиться\прогнуться антитварям, ведь те "продукты", которые кричат о троянах лишь заметив подобные отклонения едва ли можно назвать средством обеспечения безопасности. Но ложноположительных отчётов слать придётся меньше. Почему не решить проблему проще?
И всё же некоторые из перечисленных пунктов просто небезопасны (RWX на секцию кода) или некорректны (Size Of Stack Reserve не кратен размеру страницы, название секции ресурсов — всё же есть рекомендации называть её ".rsrc", секция ".idata" могла бы иметь флаг назначения — (Un)InitializedData, а не только атрибут прав доступа на чтение).
Попробую помочь.
Я работаю в антивирусной компании и вижу, что мы отмечаем как вирус.
Если есть возможность получить все версии Fresh IDE, то мы их добавим в проверочный набор и научимся диагностировать правильно.
Как раз вчера впервые увидел такое окно и некоторое время смотрел на него в недоумении — как так, всего одна кнопка, причем совсем не та, которая мне нужна. Потом всё-таки нажал на More Info, оказалось, запустить можно оттуда. Но я, конечно, немного выругался.
(запускал небольшую утилитку, которая входит в другой пакет. Из главной программы запускается без проблем, а при простом запуске.ехе вылезло это предупреждение. Я потому и думал, как бы запустить, потому что знал, что это за утилита и что она работает. Было бы что-нибудь незнакомое, то закрыл бы и не парился).
(запускал небольшую утилитку, которая входит в другой пакет. Из главной программы запускается без проблем, а при простом запуске.ехе вылезло это предупреждение. Я потому и думал, как бы запустить, потому что знал, что это за утилита и что она работает. Было бы что-нибудь незнакомое, то закрыл бы и не парился).
Это основная причина, по которой я ушел из десктопной разработки хобби проектов под винду.
Сначала нашел обходной вариант, что винда не ругается, если скачать и установить интерпретатор Питона, а затем им запускать скрипты с моими поделками, а потом понял, что в таком случае и винда не нужна, и теперь все мои программы, написанные на Питоне, по умолчанию идут для Linux дистрибутивов, иногда с веб-мордой. На винде проверяю только в том случае, если это заказная разработка и заказчик оплатил отдельной строкой совместимость с виндой.
В данный момент два проекта в разработке, уже больше 1000 постоянных пользователей. Действительно смарт скрин сбивает людей с толку.
Но мне кажется, что таким образом, он свою пользу сведет к 0. По крайней мере в русском сегменте, очень много софта, без подписи, и пользователи банально привыкнут нажимать эти галочки, и пропускать уведомления смарт скрина. Просто будут замылены глаза, тем самым хорошая идея, которую можно было бы сделать отличной, станет абсолютно ненужной.
Но мне кажется, что таким образом, он свою пользу сведет к 0. По крайней мере в русском сегменте, очень много софта, без подписи, и пользователи банально привыкнут нажимать эти галочки, и пропускать уведомления смарт скрина. Просто будут замылены глаза, тем самым хорошая идея, которую можно было бы сделать отличной, станет абсолютно ненужной.
Сталкивался с необходимостью покупки Code signing EV для подписания своего драйвера. Сначала попрбовал самый дешевый certum. Даже заплатил. Но что-то не то нажал в интерфейсе и потом попросил вернуть деньги и они вернули.
Потом нашел знакомого ИП-шника, который согласился, чтобы от его имени заказали сертифика. В сертификате будет что-то типа IP Ivanov Ivan Ivanovich.
Начал попробовать Globalsign. Из всех оказалась самой адекватной, так как есть поддержка на русском языке и тётя говорит, что и как делать. И я почти был готов заплатить несчастные 26тр за сертификат, как начались катаклизмы. Сначала сгорел офис, потом корановирус. И я подумал — «ну его нафиг».
Потом нашел знакомого ИП-шника, который согласился, чтобы от его имени заказали сертифика. В сертификате будет что-то типа IP Ivanov Ivan Ivanovich.
Начал попробовать Globalsign. Из всех оказалась самой адекватной, так как есть поддержка на русском языке и тётя говорит, что и как делать. И я почти был готов заплатить несчастные 26тр за сертификат, как начались катаклизмы. Сначала сгорел офис, потом корановирус. И я подумал — «ну его нафиг».
Очевидно, MS опять пытаются заскочить в ушедший поезд и сделать свой AppStore с преферансом и блудницами.
Это все ПО от разработчиков. А вот теперь представьте корпоративный софт, который для каждого хоста (или группы) создает кастомные инсталляторы. Естественно не прошедшие проверку в МС и не подписанные.
Резонно. Майкрософту выгодны не куча мелких разрабов, с каждыми из которых нужно разбираться отдельно и сложно, а гиганты вроде адоба с командой специально обученных менеджеров по договорам и бюджетами, проценты от которых сами по себе отдельный бюджет.
Туда и дорога.
Туда и дорога.
Автор еще не знает что главный враг не Smart Screen.
Хуже всего Google Safe Browsing.
Это убожество не реагирует на тип сертификата.
Им все равно кого банить. И у них намного больше процент использующих Хром.
Для GSB в порядке вещей выписывать надписи Uncommon Downloads без указания файлов которых это касается.
Они заблокировали Far Manager и многое другое.
Зато всякая последняя рекламная шваль цветет и пахнет вместе с этим “защитнигом”
И не очень заметно прошла новость о том что GSB в новых версиях Хрома получает все больше данных о посещениях и скачиваниях, а не только хэши.
Для Гугла и хэши преобразовать не очень большая проблема.
Вопрос, почему откровенную адварь они пропускают, зато как собаки кидаются на вполне нормальные программы.
Хуже всего Google Safe Browsing.
Это убожество не реагирует на тип сертификата.
Им все равно кого банить. И у них намного больше процент использующих Хром.
Для GSB в порядке вещей выписывать надписи Uncommon Downloads без указания файлов которых это касается.
Они заблокировали Far Manager и многое другое.
Зато всякая последняя рекламная шваль цветет и пахнет вместе с этим “защитнигом”
И не очень заметно прошла новость о том что GSB в новых версиях Хрома получает все больше данных о посещениях и скачиваниях, а не только хэши.
Для Гугла и хэши преобразовать не очень большая проблема.
Вопрос, почему откровенную адварь они пропускают, зато как собаки кидаются на вполне нормальные программы.
Скажите, пожалуйста, а как бороться с защитником виндовс или заработать его доверие?
Разрабатываю простенькие утилитки для себя самого в первую очередь. Выкладываю их на своей домашней страничке если кто-то заинтересуется, но в первую очередь для самого себя.
Пишу их на python и собираю pyinstaller, так как у меня несколько компов дома, но интерпретатор для разработки только на одной машине.
Программа полностью написана мной и собрана также только мной, так что никакими вредными действиями не занимаюсь, смысл вредоносить самому себе.
И чтоже, этот якобы «защитник» именно в кавычках, постоянно удалял мою программу. Я конечно добавил потом папку с ней в исключения, но все равно, что за ерунда. А если я хочу с друзьями поделиться, или в будущем начать распространять какое-то ПО, то откуда взять репутацию, если защитник удаляет программу даже у самого разработчика.
Пишет в журнале следующее:
Категория: Троян
Описание: Эта опасная программа выполняет команды злоумышленника.
Рекомендуемое действие: Немедленно удалите это программное обеспечение.
подробности:
Trojan:Win32/Wacatac.D!ml
Прочитав такое у чужой программы — сразу репутацию разработчика в минус, но это ведь я сам писал.
И уровень угрозы критический. Вот с чего я заработал такое на ровном месте. В программе нет ни строчки по работе с почтой, и даже с интернетом. Может в будущем и буду делать сетевое подключение, но пока программа полностью локальна, работает только внутри своей папки с файлом sqlite базы своей. Все, больше никак не взаимодействует с сетью, файловой системой или ОС.
Разрабатываю простенькие утилитки для себя самого в первую очередь. Выкладываю их на своей домашней страничке если кто-то заинтересуется, но в первую очередь для самого себя.
Пишу их на python и собираю pyinstaller, так как у меня несколько компов дома, но интерпретатор для разработки только на одной машине.
Программа полностью написана мной и собрана также только мной, так что никакими вредными действиями не занимаюсь, смысл вредоносить самому себе.
И чтоже, этот якобы «защитник» именно в кавычках, постоянно удалял мою программу. Я конечно добавил потом папку с ней в исключения, но все равно, что за ерунда. А если я хочу с друзьями поделиться, или в будущем начать распространять какое-то ПО, то откуда взять репутацию, если защитник удаляет программу даже у самого разработчика.
Пишет в журнале следующее:
Категория: Троян
Описание: Эта опасная программа выполняет команды злоумышленника.
Рекомендуемое действие: Немедленно удалите это программное обеспечение.
подробности:
Trojan:Win32/Wacatac.D!ml
Прочитав такое у чужой программы — сразу репутацию разработчика в минус, но это ведь я сам писал.
И уровень угрозы критический. Вот с чего я заработал такое на ровном месте. В программе нет ни строчки по работе с почтой, и даже с интернетом. Может в будущем и буду делать сетевое подключение, но пока программа полностью локальна, работает только внутри своей папки с файлом sqlite базы своей. Все, больше никак не взаимодействует с сетью, файловой системой или ОС.
А если в Steam выйти, допустим, со своей прогой, то тоже будет ругаться?
SmartScreen ругаться не будет. Но как пропихнуть в steam файловый менеджер, прогу учёта личных финансов или офисный пакет?
Но как пропихнуть в steam файловый менеджер
Я не в курсе. А что есть какой-то список приложений, который не пропустят?
Я не видел в стиме ни браузеров, ни pdf-ридеров.
Думаете, никто не додумался продавать неигровой софт через стим, и у вас просто так прокатит?
Думаете, никто не додумался продавать неигровой софт через стим, и у вас просто так прокатит?
https://store.steampowered.com/app/1189750/WinTweaker/
В Steam есть и такое. Чувак 10 кнопок сваял и думает, что настроил 10, но продает же. Так что...
А в чем прикол/польза ЦП для приложения, кроме просто «отжима» денег, если ее может купить кто угодно? Как я понял, никто ничего не проверяет и наличие/отсутствие подписи не говорит практически ни о чем.
Буквально вчера читал «Защита на основе репутации» и блокировка ПНП в Windows May 2020 Update. Возможно начинающим разработчикам будет еще хуже. Скорее всего спасение утопающих — дело рук самих утопающих. Т.е. возможно начинающим имеет смысл рассмотреть вопрос о покупке одной подписи, например, на двоих или троих. Ну или договориться с кем-нибудь у кого есть подпись с расширенной проверкой, чтобы он подписывал дистрибутив за определенную сумму…
Мой репак для GoodbyeDPI, ко ОРВИ автоматически распаковывает скомпилированную программу в папку винды и создаёт службу (заодно и прописывает ярлыки в Пуск для возможности удаления и перезапуска службы), недолго блокировался SmartScreen: не смотря на очень узкий круг распространения, уже примерно через месяц этот репак перестал блокироваться, без всяких сертификатов.
Не, ну хотя бы есть способ запуска!
А вот *плохой* Avast как делает?
Или тупо не даёт запустить приложение, обещая когда-нить в далёком будущем разрешить это, когда облачные технологии проверят его (ага, щаз).
Или запускает в песочнице на несколько секунд, после чего спустя эти секунды убивает процесс (а юзер уже мог начать работу с приложением, но оно у него бац — исчезает из-под носа) и стартует заново в обычном режиме.
А вот *плохой* Avast как делает?
Или тупо не даёт запустить приложение, обещая когда-нить в далёком будущем разрешить это, когда облачные технологии проверят его (ага, щаз).
Или запускает в песочнице на несколько секунд, после чего спустя эти секунды убивает процесс (а юзер уже мог начать работу с приложением, но оно у него бац — исчезает из-под носа) и стартует заново в обычном режиме.
Оставлю это тут:
Как воспроизвести в виртуальной машине:
1. Ставим Windows 10, находим в интернете инструкцию, как сделать Offline установщик для Visual Studio и скачиваем его на второй жесткий диск в данную виртуальную машину. Выключаем виртуалку.
2. Создаем ещё одну виртуальную машину и ставим в неё Windows 10 с отключённой сетью (без интернета). Подключаем жёсткий диск с оффлайн установщиком Visual Studio (от виртуалки п.1). Пытаемся запустить установку vs_setup.exe
Видим, что даже сама Microsoft себе не доверяет.
2. Создаем ещё одну виртуальную машину и ставим в неё Windows 10 с отключённой сетью (без интернета). Подключаем жёсткий диск с оффлайн установщиком Visual Studio (от виртуалки п.1). Пытаемся запустить установку vs_setup.exe
Видим, что даже сама Microsoft себе не доверяет.
Вас удивляет, что система не может подтвердить валидность сертификата без интернет?
ответ на коммент ниже (sumanai)
для уверенности в валидности сертификата (в том числе факта, что промежуточные сертификаты и сам сертификат не был отозван на момент подписания) используется OSCP-протокол. И он как раз требует наличия интернет. Также вполне вероятно, что для только что установленной ВМ могут быть не обновлены списки отзыва — то есть и они могут быть просрочены.
ответ на коммент ниже (sumanai)
для уверенности в валидности сертификата (в том числе факта, что промежуточные сертификаты и сам сертификат не был отозван на момент подписания) используется OSCP-протокол. И он как раз требует наличия интернет. Также вполне вероятно, что для только что установленной ВМ могут быть не обновлены списки отзыва — то есть и они могут быть просрочены.
UFO just landed and posted this here
Ну в данном случае была установлена последняя версия Windows, я думаю, что она вышла намного позже, чем Visual Studio 2019, следовательно свой сертификат она бы должна была проверить и довериться ему, даже имея оффлайн доступ, а тут что-то не так, что-то опять не доделано. Рейтинг самой себе Microsoft что-ли не добавила для оффлайн установки?
Windows Defender SmartScreen вредит независимым разработчикам