Как стать автором
Обновить

Комментарии 305

Ровно как и нотаризация для Mac OS
А чем ТАК уж проблематична в этом плане именно нотаризация?
Требование Developer account — ну так если вы разрабатываете под macOS у вас он видимо и так есть (а если нет — не такая уж проблема получить)
То, что процедура выпуска релиза начинает зависить от отсылки файлов Apple'у? Ну так а был хоть раз случай когда на нотаризацию прилетал необоснованный отказ?

Аналог того что в статье — у Apple это гейткипер — про который в принципе все кто ставят софт — знают и как отключать/обходить в конкретном случае — знают. При этом для тех же Homebrew пакетов это вообще не проблема.
достаточно распостранять инсталляторы в архивах и никакой смартскрин не страшен ;)
Боюсь что нет. Как образчик — «драйверы торгового оборудования» от атол версий 8.16.4...8.16.6 — там была куча веселостей с [не]установкой подписанного драйвера usb-serial и запозданием появления репутации на пару-тройку версий. В свое время весело читался форум их поддержки (все подписано, файлы в мс отправлены).
Ага. Глядя на них мы тоже решили не заморачиваться с подписью. Что с ней что без неё были проблемы. А теперь из статьи понятно почему. Душат нашего брата.
Душат нашего брата.
Точнее навязывают дорогой продукт. Как я понимаю EV сертификате счастье будет омрачено только расходами на него)
Душат [ФИНАНСОВО] нашего брата
Об этом речь в статье и идёт.
я уже не одну тысячу инсталляторов раздал в архивах — и никаких проблем со смартскрином
«с моей стороны пакеты ушли»)
А по факту — тот самый пример на слуху про атол — там юзеров не меньше. Притом проблемы у людей возникали просто стохастически. Типа партия компьютеров-клонов (из одной поставки с OEM виндой и с идентичным софтом) из них на 9 драйвер ставится, на 10 — нет…
Windows при загрузке zip выставляет файлу атрибут что он «с интернета» и далее если в проводнике в него войти и запустить exe — применяет к нему ту же политику что и для напрямую скаченных exe. Можно зайти в свойства файла и поставить галочку «разблокировать», но обычно это никто не делает.
Конечно если вы zip каким то WinRar распаковываете а не встроенным способом, то тогда этот атрибут при распаковке потеряется и сообщения не будет.

И кстати EV сертификаты уже не помогают. Помогает только тысяча-две скаченных и запущенных файлов другими пользователями чтобы у майкрософта набралась статистика на этот сертификат.
Поэтому раздавать надо в 7z.
Если хочется стандартного, то в ISO — монтирует по клику, а внутри своя FS, без лишних потоков
Если вы друзьям раздаете, или что то бесплатное, то все равно в чем вы там упакуете.
А если продаете свой небольшой продукт через сайт (а именно по таким в первую очередь ударяет smart screen), то разную экзотику просто не поймут, и соответственно не купят.
и при распаковке и запуске инсталлятора — привет SmartScreen
Это почему?

При скачивании браузер добавляет к файлу NTFS-stream с именем Zone.Identifier, куда помещает ссылку, откуда скачан файл. SmartScreen ругается именно на файлы с этим NTFS-потоком.

Если файл распакован из 7z-архива (к примеру), архиватор этот поток не дописывает к файлу.
Вы путаете.
Это не имеет никакого отношения к сертификату. Скрытый поток — это локальная штука в рамках одной конкретной машины, а смарт-скрин работает с облачным сервисом.
Пока вы не снимете галочку в свойствах файла операционка не даст вам обратиться к скачанному из интернета исполняемому файлу, каким бы сертификатом он не был подписан.
Это не совсем так, если репутация высокая, файл запустится сразу же, не смотря на NTFS-поток (пример). Насколько я помню, анализируется не только сертификат, но и пути распространения.
если у файла нет Zone.Identifier то смартскрин не обращает на него никакого внимания
Пока вы не снимете галочку в свойствах файла операционка не даст вам обратиться к скачанному из интернета исполняемому файлу, каким бы сертификатом он не был подписан
Именно что к скачанному, а реализуется этот механизм через добавление NTFS-потока браузерами. А если файл распакован из архива (или появился на машине пользователя например компиляцией из Visual Studio), SmartScreen не срабатывает.
Предполагаю такую логику: Если пользователь смог разархивировать, то это уже продвинутый пользователь, ему SmartScreen не нужен.
По классике :)
Я тоже хакер, я сменил обои
Ах вот откуда все эти тысячи программ, которые запросто могли бы работать как экзешник, но зачем-то требуют root-next-next-finish :(
это он еще непробовал драйвер под десяточку написать/подписать, вот где веселье так веселье
Там хотя бы фиксированный алгоритм, никаких оценок и репутаций. EV-сертификат, Attestation-подпись — всё, драйвер загрузился.
Обычному разработчику-физлицу, конечно, это недоступно, да. Ну так это не вчера началось, а ещё в Висте, когда в 64-битные винды запретили грузить драйверы, не подписанные покупным сертификатом. Помнится, и обычный-то сертификат для подписи драйверов физлицу невозможно было купить (а может, и до сих пор невозможно).
Кстати, я тоже читал, что конкретно для Win10 драйвер ядра нужно подписывать только EV-сертификатом, однако подписал это и драйвер прекрасно работает везде, включая Win10 x64, хотя сертификат самый обычный (был куплен, когда DigiCert ещё не свернули программу для Sysdevs).
Там на самом деле есть несколько условий, при которых обычная (не-MS) подпись принимается системой. Все наизусть не помню, но ключевые:
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.
Было бы интересно разобраться, что именно заставляет десятку принять эту подпись. Тем более, что она SHA-1, а вроде бы, они энное время назад перешли исключительно на SHA-256. А может, именно в этом и дело; скажем, SHA-1 считается устаревшей и для её обработки включаются старые механизмы проверки, не учитывающие новые требования…

Да, достаточно обычного сертификата. С EV просто не будет возникать окно с подтверждением издателя. Несколько сложнее, см. коммент выше.


Кроме того, если менялся только .inf, а .sys уже подписанные, то можно вообще воспользоваться libwdi для автоподписания .cat
https://github.com/pbatard/libwdi

С EV просто не будет возникать окно с подтверждением издателя.
С EV тоже будет возникать (если сертификат не был добавлен в хранилище).
Attestation-подпись получить — весьма затратный и не тривиальный процесс
Нет, это очень простой и полностью автоматизируемый процесс. Возможно, вы имеете в виду HLK/WHQL — вот с ними да, заморочек много (да и глючная у них система тестирования так, что не передать…).
Все эти цифровые подписи EV/не EV — такое глобальное, как бы так поцензурнее выразиться, разводилово. Но слово, другое подходит больше. SmartScreen это еще пол беды, другие антивирусы в принципе, зачастую, игнорируют наличие цифровой подписи. Всю историю нашего продукта мы воюем с антивирусами. Многостраничные, практически ежегодные, переписки идут практически со всеми известными вендорами.

Если обобщить — антивирусы плевать хотели на ЦП, это довольно ничтожный фактор, который иногда играет даже в минус, в том случае, если в базе есть, к примеру, предыдущая версия продукта с такой же ЦП, но на которую не оформлен / не рассмотрен рапорт о 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. Удивлён, что в статье описывается покупка сертификата на физ. лицо. Либо правила продажи изменились, либо на физ. лицо нельзя было продавать сертификаты россиянам: несколько компаний требовали либо ИП, либо фирму.

Если "не 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. Пока писал, выше то же самое запостили.

Ну блин, у вас так все просто: зайки кушают морковку, волки кушают заек. Сажайте меньше морковки, чтобы было меньше злых волков.


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

Обычно «вирусы и шифровальщики» используют уязвимости вполне легитимных и правильно подписанных программ. Ведь гораздо проще заставить пользователя запустить уже известное ему популярное ПО, чем какой-то непонятный exe.
А если разработчик распространяет ПО бесплатно, почему он всегда должен быть недоверенным или вообще платить за сертификацию? ПО должно быть дружелюбным для пользователя независимо от цены.
потому, что некий независимый разработчик — не основная целевая аудитория ОС. Безусловно, что разработчики являются важной компонентой общей «биосферы», но не основной, тем более — независимые энтузиасты.
Если меназим защиты слишком часто дает false positive — пользователи првыкают к тому, что этот механизм не работает. И начинают его игнорировать.

Много крутого софта пишется по фану энтузиатсами. У которых есть желание вложить свои силы в разработку и раздать результат бесплатно, но нет желания платить живые бабки кому-то, чтобы раздавать результат бесплатно.
1. если я скачаю Google Chrome, а при установке он мне выдаст недоверенный сертификат — это бинго, сработало.
2. если я скачаю некое ПО, а его разработчик не озаботился валидным сертификатом разработчика — это тоже звоночек. Как веса в антиспаме — сам по себе не повод отказаться, но при прочих равных предпочту подписанный софт.
Ну если бы оно работало так как вы говорите то это было бы отлично.
Вот только работает не так. О чем и говорится в статье.
Собственно смотрите пример с паленым скайпом ниже:
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 не нужны разработчики как предприниматели и продавцы своего продукта, а нужны как рабочая сила в отделах автоматизации больших предприятий.


Не совсем так. По общему движению видно, что им три вида разработчиков нужны:

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.
Эм… довольно давно использую Open-Source версии VS Code. Ранее пользовалась VSCodium (из репа @paulcarroty), сейчас использую Code — OSS из репозитория Арча, и майкрософтовский репозиторий в обоих случаях доступен.
Пруф

Для подписи драйвера, как писали выше, уже давно нужен EV сертификат. Но сейчас этого мало, технически нужно этот сертификат просто подтвердить, подписав им болванку от MS, а непосредственно подпись драйвера осуществляется на серверах MS их сертификатом.
Open Source, если говорить о third-party, либо уже подписан издателем, либо может быть подписан вашей собственной подписью перед упаковкой в инсталлятор. Никаких проблем с Open Source по поводу цифровой подписью не наблюдал ни разу.
Другое дело, конечно, если вы пытаетесь использовать готовый Open Source продукт без подписи, но в этом случае если вы пользователь — проверяете бинарники на VirusTotal и говорите SmartScreen, что всё в порядке.
Если вы разработчик Open Source и выпускаете в мир неподписанный софт — вы ведь всё равно не ожидали прибыли от продукта. Если выпускаете подписанный свежим сертификатом — просто выжидаете время, пока количество установок не перевалит значения, достаточного для того, чтобы SmartScreen перестал на ваш сертификат реагировать.
Я не ожидаю прибыли. Но я ожидаю что продуктом будут пользоваться. И уж точно я не ожидаю что моим продуктом будут пугать пользователей.
Но массовый пользователь от этого очень даже выиграл. В эру до смарт скрина было намного легче попасться на удочку, когда скачал фэйковый установщик известной программы и установил своими руками троян. С появлением скрина хотя бы можно заметить, что skype.exe то не настоящий, потому что без подписи и сходить перепроверить оттуда ли ты его скачал. Со всеми этими фишками польза от антивирусов резко упала, потому что 99% массового софта с подписями и ты понимаешь, что ставишь софт от производителя, а не от васяна.
Только вот все распространители левого ПО просто обзавелись сертификатами, у них же бизнес. А любители на этом не зарабатывают.
Вот первая попавшаяся софтина по запросу «Скачать скайп бесплатно без СМС». Размер 2 мб, позавчерашняя подпись и 39 детектов на вирустотале.
Заголовок спойлера



SmartScreen естественно не сказал ни слова, только UAC «стоит на страже» персональной информации
Заголовок спойлера


Ну а в итоге программа не смогла без интернета
Заголовок спойлера


Так кому там стало проще?
Отличный коммент. Самому лень такое исследование было сделать со скриншотами, потому не стал про это упоминать тут. Вот оно все лицемерие всей индустрии сертификатов, в том виде, в котором она есть на данный момент.
Т.е. вы предполагаете, что вот эти ребята — installpack.net — распроcтраняют вирусы? Или таки они просто занимаются не очень одобряемой упаковкой и без того доступного ПО в свои инсталлеры с добавлением сверху всякой «пурги» типа Я браузера и всяких «ускорителей» инета? Во 2ом случае они просто не совсем чистые на руку предприниматели, но никак не malicious guys.

ps. прошу прощения, но не смогу оперативно отвечать на злободневную тему — защитники конечных пользователей решили, что я — неправильный пользователь. :-D
Во 2ом случае они просто не совсем чистые на руку предприниматели, но никак не malicious guys.

Только в процессе своей работы эта программа обращается как минимум к 7 интернет адресам, начиная от «безобидной» гугл аналитики, и заканчивая скачиванием JS файла со своего сервера и последующим его исполнением. Да, сейчас там только список получаемых откатов от различных разработчиков втюхиваемого софта. Но кто может гарантировать, что завтра там не появится команда на установку зловреда? Кто может гарантировать, что это ПО не ставит зловреда например только на Ryzen 3900? Я вот не могу этого гарантировать.
В 2012м я сделал бесплатно сертификат от нортона (на сайте нортона).
Делал специально, чтобы Windows определял мой софт как от «благочистивого» разработчика.
С тех пор и подписываю им.
Специально сейчас проверил самые старые установщики и .exe — смарт-скрин на них не ругается.
Вопрос, это мне сильно повезло и следует беречь сертификат как зеницу ока, или же я что-то делаю(проверяю) не так?
Обычно сертификат выдаётся на 1-3 года, после чего превращается в тыкву и годится разве что для подписи драйверов без штампа времени, а уж о бесплатной раздаче вообще не помню.
Если софт не содержит каких-либо подозрительных системных вызовов, т.е. в чистом виде прикладной и простой с т.з. различных эвристик антивирусов, то и без всяких сертификатов его детектить не будут.
Софт без защиты — очень легко взломать, и сделать его полностью бесплатным.
Софт с защитой вызывает срабатывание антивирусов.
Мы всё ещё про смарт-скрин говорим?
Для того, чтобы избежать подобной ситуации достаточно:
1) Всё-таки приобрести сертификат. Стоит не такие уж космические деньги и даёт определённую защиту от взлома.
2) Потратить немного усилий на тестирование своей программы. По моему опыту достаточно одной-двух недель установок релизной версии программы для того, чтобы сертификат успел засветиться как «безвредный». Репутация рассчитывается не по положительным отзывам, а по комбинации количества установок и количества жалоб.
Не исключено, что что-то изменилось за пять лет (когда я первый и последний раз столкнулся со впервые выпущенным для компании сертификатом), но тогда это работало именно так. Неделю видел смарт-скрин при установке, после этого попустило. Кроме меня (разработчика) это приложение устанавливал только тестировщик. Т.е. количество уникальных машин какого-то значения не имело — только количество установок и/или отсутствие жалоб в течении какого-то времени после первого запуска инсталлятора со свежевыпущенным сертификатом.
Если всё работает так как вы описываете — то система репутации вообще полный бред и тупость.
Хуже. Делается ПО. Неопознаваеморе неким антивирусом. В присутствие этого антивируса запускается ххх раз. Репутация. А вот теперь как пользователь пробейтесь на поддержку чтобы сообщить, что ПО — редиски и изменить вердикт облака репутации
и даёт определённую защиту от взлома

А поподробнее? Я что-то не вижу связи.
Пример по дотнету.
Допустим у вас большое приложение из многих библиотек. Защита вашего приложения живёт в одной из них. Обфускатор, конечно, помогает, но гарантии от получения компилирующихся исходников не даёт — вопрос желания.
В конце-концов бинарник можно декомпилировать в IL. Если взломщик обладает навыками работы с IL — вариант вполне рабочий.
Или даже прямая правка бинарника без декомпиляции. Чтобы заменить какую-нибудь строку, например.
В общем взломщик обходит защиту в бинарнике любым способом, получает взломанную библиотеку, подкладывает в рабочую папку приложения с заменой оригинала и получает свободно распространяемый бинарник.
Если все библиотеки вашего приложения подписаны — подключить модифицированный бинарник без подписи дотнет не даст. И даже подпись другим сертификатом не пройдёт — компоненты, которые ссылаются на модифицированную библиотеку откажутся загружать её, если Public Key не соответствует оригиналу.
Т.е. остаётся вариант полной пересборки всех бинарников вашего приложения без подписи или с подписью другим сертификатом.
Если даже бинарник редактировался без декомпиляции, то модифицированный файл не пройдёт проверку подписи по контрольной сумме.
Не сильно вдавался в тему сложно ли обойти защиту от загрузки библиотеки с несоответствующей подписью, только знаю, что легальных способов для этого дотнет не предоставляет.
Кроме того, на моей памяти есть один очень давний случай, когда в процессе разбирательства с проблемами у клиента была обнаружена пересобранная не нашей компанией библиотека. Сразу после этого директор наконец-то решился «раскошелиться» на сертификат, до этого никакие аргументы его не пронимали.
Тут взломщику поможет библиотека манипулирования сборками Mono.Cecil.
Она создаёт объектную модель сборки, в которой можно добавлять, редактировать и удалять типы (классы), методы, поля, инструкции IL-кода, ссылки (references). Затем модель сериализуется обратно в бинарный файл. Процесс достаточно надёжный, на нём работает Mono, PostSharp и Fody. Достаточно будет найти и заменить strong name reference на обычную, по имени DLL.
Оригинальное решение, не сталкивался.
Насколько я понял — это позволяет подменить reference с подписанной оригинальной библиотеки на неподписанную взломанную. Но разве .Net позволяет референсить неподписанные библиотеки из подписанных?
Компилятор такого точно не позволяет, или в runtime дополнительной проверки нет?
Хотя, при таких возможностях Cecil подозреваю, что можно заменить один strong name reference на другой, но для этого всё-таки придётся чем-нибудь подписать взломанную библиотеку.
Если мне не изменяет память, то в рантайме проверка всё же есть — Assembly.Load не позволит загрузить неподписанную библиотеку в AppDomain, созданный подписанным exe.
разве .Net позволяет референсить неподписанные библиотеки из подписанных?
Но патчить нужно приложение, а не DLL. Ну и всё вверх по зависимостям, если подменённая DLL референсится из какой-то подписанной.
Спасибо за подробный комментарий.
Мне не нравятся приложения, требующие какой-либо установки.

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

Лучшее, что я видел, приложение состоящее из одной exe. Оно просто запускается и работает.
НЛО прилетело и опубликовало эту надпись здесь
Я когда начал распространять своё приложение, так и сделал сначала. Был обычный exe файл упакованный в zip архив. После скачивания, предполагалось что пользователь распакует его в удобное для него место. После запуска приложение создавало в той же директории папку с логами, файл с настройками и т.д. Всё создавалось в той же папке из соображений, что если пользователь захочет удалить программу, то он просто удаляет папку.
Но, по мере того как всё больше людей стало пользоваться моей программой столкнулся с проблемой, каждый третий норовит распаковать в папке Program Files. А в современных версиях Windows, по умолчанию, там писать нельзя. Поэтому как то само собой и перешёл на инсталятор, а все настройки храню в ProgramData.
Здесь есть в меру простое решение проблемы: если нет доступа на запись в текущую папку, надо сругаться и спросить, устроит ли пользователя хранение настроек и логов в такой-то папке (ProgramData или AppData — в зависимости от того, нужны вам настройки этой программы общие для компьютера или отдельные для пользователя).
Тогда мы возвращаемся к вопросу о том, что в системе останется мусор после удаления папки с программой. Т.к. папка с логами и настройками будет находиться в другом месте, да и запись об этой папке где то должна храниться. А пользователь, вряд ли вручную будет систему подчищать.
Поэтому и получается, что проще инсталятор сделать, и в нём при удалении прописать очистку.
Проблема портабельных программ это в том, что если программа будет запускаться на частой основе(а не программа на 1-2 раза), то этот экзешник надо будет класть в соответствующее место иначе папка загрузки/рабочий стол просто замусорится. И это придётся делать вручную, класть в програм файлс, делать ярлык на рабочий стол и в пуск.

Портабельные программы нельзя в Program Files класть. Они всегда пишут только в своей директорией, а это Windows категорически не нравится. Хотя казалось бы что это самое безопасное поведение.

Я бы не был так категоричен по поводу
Они всегда пишут только в своей директорией
Тут как автор программу реализует и какие данные пишутся. Это вполне может быть и профиль пользователя, в который все нормально пишется.

Это да, конечно. Но вообще-то идея портабельности идет в разрез с того чтобы писать где нибудь еще, кроме в собственной директории. Ведь, если программа поставлена на переносном носителе, то все данные потеряются, когда включим этот носитель на другом компьютере.


А так — согласен — всякое бывает.

Хотя казалось бы что это самое безопасное поведение.

Это самое небезопасное поведение — разрешать запись в Program Files от лица пользователя.
По хорошему должно быть только 2 типа каталогов — в которые можно писать, но из которых нельзя запускать, и из которых можно запускать, но нельзя писать (простому пользователю). Такая система прав защищает от большей части угроз современного интернета, и она была предусмотрена при разработке ядра NT. Но потом пришли разрабы с кривыми руками, пришли менеджеры, которым нужна совместимость с написанным криворукими программистами софтом, и мы имеем что имеем. Программы запускаются откуда ни попадя, и запретить это сложно, так как они норовят установится в AppData, чтобы не пугать пользователя запросом UAC. Конечно, тут есть вина Microsoft, что они не предусмотрели централизованной системы загрузки и обновления ПО, но от этого никому сейчас не легче.
Вы не правы. Разрабы пришли ДО того как NT получил распространение. И исходили из той модели, которая тогда была в 9x. А потом просто слишком много legacy было, чтобы что-то менять.
Да. Только вот всех дико испугала Vista, в которой эти политики наконец-то начали применятся, а рекомендации по правильному написанию софта были задолго до XP. То есть разрабы минимум 7 лет писали не по гайдам. Я не верю, что из них большая часть была махровым легаси, написанным под Win95. Так что я останусь при своём.
Гайды? В 90х? Не смешно.
Серьёзные производители софта, тем не менее, давным-давно выполняют эти требования. Более того, в мире *nix-подобных систем, в общем-то, всё то же самое. Обычный пользователь может писать в свою домашнюю директорию, но не может из неё запускать. Правда, ещё tmp может быть.
Куча серьезных производителей софта клали на эти требования. Например гугл с хромом.
В мире *-nix так было всегда. Если бы так было изначально в винде — никто бы не бухтел и все бы так изначально и делали.
Ну и вы ошибаетесь — обычный пользователь без проблем может запускать софт из своего домашнего каталога. Не скажу за все никсы, то в линуксе точно может.
Ну и вы ошибаетесь — обычный пользователь без проблем может запускать софт из своего домашнего каталога. Не скажу за все никсы, то в линуксе точно может.


Собственно, опциями монтирования регулируется. Тут скорее корректнее будет «в линуксе опциями монтирования такой результат достигается на раз-два, но, из-за моды на юзерспейсные установщики, дефолтное поведение на данный момент, к сожалению, монтирование хомяка без noexec-опции»
Ну, собственно, всё ровно так же, как и в Windows.
Не заметил идентичности.

Linux имеет:
1. Опцию монтирования noexec, которая по факту монтирования позволяет запретить исполнение файлов в разделе вне зависимости и без исправления как таковых любых прав/параметров и т.д. самой файловой системы. К слову, дефолтный noexec на хомяка в последнее время не ставят — это да. А на флешки — вполне себе, т.е. уже польза.
2. Раздельные права на исполнение и чтение файла как атрибуты ФС. Т.е. а) можно разрешить читать, копировать, whatever файл, не позволяя запуск, б) можно разрешить исполнение, не позволяя чтение.
3. AppArmor/SELinux — дополнительный слой, позволяющий дополнительно ограничивать права.

В Windows, как я понимаю, аналогом AppArmor/SELinux можно частично считать UAT или как оно там зовется. А аналоги первых двух — как с ними?

В общем, совершенно не так же, и абсолютно не ровно.
1-2. Опций монтирования в Windows нет, но права доступа на запуск и просмотр содержимого каталога отдельные.
По третьему для запрета запуска программ есть SRP/AppLocker, а какие-либо дополнительные системы прав не нужны, так как разрешения NTFS изначально достаточно гибкие.
А про ровно тоже самое я писал к тому, что ни в Linux, ни в Windows нельзя просто взять и запретить запуск ПО (любыми средствами) в домашнем каталоге, так как это сломает кучу кривого софта.
Разрешите немножечко попридираться:

права доступа на запуск и просмотр содержимого каталога отдельные


В линухе права на запуск файла и на просмотр содержимого запускаемого файла — сущности различные. Т.е. вы можете дать право запускать без права посмотреть, что внутри. Иногда это полезно, и всегда забавно.

Опций монтирования в Windows нет


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

А про ровно тоже самое я писал к тому, что ни в Linux, ни в Windows нельзя просто взять и запретить запуск ПО (любыми средствами) в домашнем каталоге, так как это сломает кучу кривого софта.


Не совсем то же самое. В Windows отсутствует простая и при этом стопудово гарантированная возможность запретить исполнение любых файлов из хомяка, проигнорировав проблемы кривого софта. В Linux такая возможность есть.

Т.е. в Linux не работает из-за кривого софта, а в Windows — и с прямым тоже не работает.
Т.е. вы можете дать право запускать без права посмотреть, что внутри.

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

Говорю же, SRP/AppLocker. Есть как чёрный, так и белый список. Гарантированно.
Для негарантированного есть права доступа. Просто там можно будет отключить наследование и выставить разрешение на запуск. Но этого конечно никто не догадается сделать, как обычный пользователь, так и любое известное мне ПО.
Ну вот собственно, из дефолтной разницы — с флешек в линухе ничего не запускается.
Так прям ничего не запускается? Если я сделаю двойной клик по 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, тогда его не будет вообще ни каком файле.
Немного стало понятнее. Двойной клик по файлу работает по-разному, в зависимости от наличия атрибута '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 и запускать правой кнопкой, либо это всё будет автоматизированно в «новом удобном браузере Амиго».
Понятно, почему в 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 на нес-ко голов.

Поддерживаю.
по части разрешений 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-троица, собственно, проектировались с прицелом на распределение прав внутри одной существующей функционирующей системы. Перенос ФС на другую машину «как есть» работает одинаково плохо для обоих наборов прав — они не на то рассчитаны были.
И даже если вы групповыми политиками запретили запуск с флешки, этот exe-шник все еще можно скопировать в хомяк и запустить оттуда.

Поэтому единственно безопасной конфигурацией является запрет на запуск всего, что не в Windows или Program Files.
А что насчет программ, которые устанавливаются в %LOCALAPPDATA%? Или тех, которые сам компилируешь? Я понимаю, что скорее всего Вы предложите запретить и это, но в том же Linux такое не запрещено и на безопасность никто не жалуется.

Кстати, а bat/ps файлы считаются исполнимыми? А другие скрипты (python, например)? А то так можно и до whitelistallowlist дойти, в котором только calc.exe и notepad.exe будут (естественно, с полными путями и, на всякий случай, хешами этих файлов).

Я понимаю, что в корпорациях админ может заблокировать всё, кроме реально необходимого минимума. Но что делать «обычным» пользователям на домашних компьютерах?

PS. Прошу прощения за легкий троллинг.
А что насчет программ, которые устанавливаются в %LOCALAPPDATA%?

Очевидно, они нарушают модель безопасности ядра NT и должны быть изменены.
Кстати, а bat/ps файлы считаются исполнимыми?

Зависит от настроек. По умолчанию да, считаются.
А другие скрипты (python, например)?

Вроде нет. Но интерпретатор питона не встроен в Windows. Впрочем никто не мешает добавить соответствующее расширение в политики.
Но что делать «обычным» пользователям на домашних компьютерах?

Ставить обычные программы, которые устанавливаются в Program Files, требуя при этом подтверждение UAC. Разработчикам программ следует наконец прочитать гайды и ставить программы куда нужно.
PS. Прошу прощения за легкий троллинг.

Прошу прощения за серьёзный ответ на троллинг.
Очевидно, они нарушают модель безопасности ядра 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?

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

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

Зачем свой. Просто 90% софта работает правильно и не отсвечивает.
Замечу, что данной фразы я не писал.


Ну да, вы писали вот эту: «Разработчикам программ следует наконец прочитать гайды и ставить программы куда нужно.»

Мне кажется, в вашей коннотации «разработчик, все еще не прочитавший гайды» имеет ярко выраженную окраску «не очень хороший разработчик», не?

Зачем свой.


Я имел в виду «свой» в значении «микрософтовский». Мне лично кажется странным, когда солидная контора выпускает рекоммендации для софта, которым не следует софт, написанный этой конторой. 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» кажется утопичной и нереализуемой хотя бы из соображений доступного дискового пространства.
Мне кажется

Вам кажется.
Visual Studio Code, тысячи их — допускают установку в «хомяк».

Допускает. Но у меня он стоит где нужно. Не использую офис, но считаю, что у него тоже есть такая опция.
Топ браузеров под Windows: Chrome, Firefox, Edge. Из этих трех в хомяк не встает только Edge

Вы не правы. Firefox встаёт куда нужно, про хром не уверен, но у него должна быть версия в msi, которая встаёт куда нужно.
Любой мессенджер (а их десятки), за исключением скайпа отлично встает в хомяк.

У меня телеграм, который из стора, и стоит в Program Files\WindowsApps. Что я делаю не так?
Так что давайте уж определимся таки: запуск приложений извне ProgramFiles — штатный механизм Windows, никоим образом «модели безопасности NT» не противоречащий.

Это штатный механизм, спору нет. Наследие Legacy. Но модели он противоречит. Иначе в принципе нельзя обеспечить безопасность ОС.
Допускает. Но у меня он стоит где нужно. Не использую офис, но считаю, что у него тоже есть такая опция.


Ну, собственно, если само наличие «опции» установки в Program Files переводит софтину из разряда «написано чуваками, которые не читали рекомендации» в разряд «нормальный софт», искренне не понимаю, в чем смысл вашего высказывания «им пора бы уже прочитать рекоммендации». Любая софтина имеет «опцию установки в Program Files», вот прям любая. Собственно, «установка в Program Files» от «установки в хомяк» отличается исключительно местоположением исполняемого файла. И даже склонность программы писать в папку, в которой она лежит, очень просто лечится установкой workdir. Короче, так и непонятно, зачем читать рекоммендации.

Вы не правы. Firefox встаёт куда нужно


И все таки, подскажите, откуда взялось понятие «куда нужно». Где конкретно указано, куда нужно складывать бинарники?

про хром не уверен, но у него должна быть версия в msi, которая встаёт куда нужно.


Зачем? Если под «куда нужно» понимать Program Files, то обычный инсталлятор хрома отлично умеет туда ставить, с единственным нюансом — при наличии прав администратора. Собственно, он поддерживает 2 штатных варианта установки: только для себя — в хомяк, и для всех — в Program Files.

У меня телеграм, который из стора, и стоит в Program Files\WindowsApps. Что я делаю не так?


Я вам подскажу: любое приложение из стора будет стоять в Program Files/WindowsApps. И это, собственно, не хорошо и не плохо, это просто данность, у которой есть свои минусы. А в целом — просто поставьте не из полумертвого стора, и сможете выбирать, куда ставить.

Это штатный механизм, спору нет. Наследие Legacy. Но модели он противоречит. Иначе в принципе нельзя обеспечить безопасность ОС.


Вот это поток сознания. Итак, по вашим же словам:
1. Это штатный механизм.
2. Штатный механизм противоречит модели безопасности.
3. Это единственный способ обеспечить безопасность.

Вот реально??? Единственный способ обеспечить безопасность системы — это чтобы штатный механизм этой системы противоречил модели безопасности этой самой системы? Вы сами понимаете, что вы несете? Вы прямо заявляете, что единственный способ достижения безопасности — это забить на модель безопасности…

Или вы имеете в виду, что есть модель безопасности, которая — единственный способ обеспечения безопасности, но штатный механизм ей противоречит, и поэтому обеспечить безопасность нельзя, и поэтому вся эта муть просто не работает, и всех это устраивает?

Ну, тоже такое себе. Подскажите какой-то другой вариант толкования ваших слов. Я дважды попытался, ересь какая-то выходит.
Любая софтина имеет «опцию установки в Program Files», вот прям любая.

Нет. Сейчас пошла мода на установку без вопросов.
Вы прямо заявляете, что единственный способ достижения безопасности — это забить на модель безопасности…

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

Можно.
Ну, тоже такое себе. Подскажите какой-то другой вариант толкования ваших слов. Я дважды попытался, ересь какая-то выходит.

Я не знаю как ещё вам объяснить.
Нет. Сейчас пошла мода на установку без вопросов.


То, что оно молча ставится, куда придумает — это я и так знаю. Но по поводу опции — покажите мне софтину, которую я в Program Files поставить не смогу.

Не представляю как вы это вывели.


Внимательно, вдумчиво прочтите вот это:
«Это штатный механизм, спору нет. Наследие Legacy. Но модели он противоречит. Иначе в принципе нельзя обеспечить безопасность ОС.»
Но по поводу опции — покажите мне софтину, которую я в Program Files поставить не смогу.

PostMan? Он вроде как раз без вопросов в профиль залетел.
Внимательно, вдумчиво прочтите вот это:

Прочитал. Не понял, как вы вывели. Я пишу о том, что чтобы обеспечить безопасность ОС, нужно игнорировать штатную возможность запускать софт откуда попало.
PostMan? Он вроде как раз без вопросов в профиль залетел.


Ну, собственно, берем exe-шник инсталлятора Postman. Это самораспаковывающийся архив, с удовольствием взглянул на «внутренности». В общем и целом, внутри иконка, чуть мишуры и NuGet-пакет.

Папка установки регулируется, если верить документации (под рукой винды нет, вечером перепроверю), тут: %ProgramFiles(x86)%\NuGet\Config. Конфиг уровня пользователя лежит здесь: %appdata%\NuGet\NuGet.Config. Вот там можно выбрать, куда ставить, включая ProgramFiles.

«Умолчания» при этом такие: %userprofile%\.nuget\packages. Вот сюда оно устанавливает пакеты. Кхм, и это — штатный рекомендуемый пакетный менеджер от MS. И эти люди запрещают мне ковыряться в носу? будут мне рассказывать, что «прочитайте уже рекоммендации»? NuGet — вполне себе рекомендованное конкретно «Майками» решение, и он мое приложение вкорячивает пользователю в «хомяк», вне зависимости от моего желания. Отличненько, еще остались люди, которые продолжат утверждать, что установка за пределы Program Files противоречит рекомендациям Микрософт.

Ну, в общем, челлендж, вроде выполнен? Порядок действий такой: правим настройки NuGet, чтобы ставил внутрь ProgramFiles, устанавливаем Postman — встает туда, куда мы определили. Я справился?

Я пишу о том, что чтобы обеспечить безопасность ОС, нужно игнорировать штатную возможность запускать софт откуда попало.


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

Что мы получаем на выходе? Штатная модель безопасности блокирует штатную возможность… Вы это, либо крестик снимите, либо рясу в трусы не заправляйте! Не должна система безопасности блокировать штатные (еще раз, по буквам, ш т а т н ы е) возможности! Иначе какие они, к чертям, штатные?
Ну, в общем, челлендж, вроде выполнен?

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

Что вам не нравится? Вы очень много придираетесь к словам, буквам и определениям. Да, одна штатная возможность блокирует другую, почему бы и нет. Там же я могу заблочить запуск хоть штатного калькулятора, если мне будет нужно.
Кстати, я сейчас на Linux, и я запускаю robo3t дабл кликом по «экзешнику» по пути /home/%username%/robo3t-1.3.1-linux-x86_64-7419c406/bin. Шах и мат?
Кстати, да. Нажатие ENTER в Midnight Commander тупо запускает исполняемый файл. А нам кто-то 500 постов подряд доказывал, что так просто, тупо по клику, ничего не запускается.
Нажатие ENTER в Midnight Commander тупо запускает исполняемый файл. А нам кто-то 500 постов подряд доказывал, что так просто, тупо по клику, ничего не запускается.


Давно нажатие ENTER в mc, с предварительным запуском этого самого mc стало «тупо кликом»?

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

Посмотрите выше. Нет, не разные. Не, возможно, корица, вредина эдакая, что-то делает не так, как вы считаете. Но по крайней мере у меня User experience ничем не отличается от виндового — дабл клик и получаю запущенную программу. Предварительно я её конечно же распаковал в хомяк, и отличий от винды тут были разве что в формате архива.
Третьегном сейчас поступает так же, явным образом подтверждаю. Второгном так не поступал, так же как KDE3. Очевидно, поведение таки принесли, лично я считаю это ошибочным решением, но это пофиг. Повторный поход по граблям можно считать открытым.
Давно нажатие 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.
Заблокированная политиками безопасности возможность перестает быть штатной же.

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

Сорян, я не профессиональный разработчик под Windows, и не знаю от корки до корки всю её документацию.
Тупо IDE-специфичное поведение, поведение одного из доступных IDE.

Проверяли то где? Я в Cinnamon, вы наверняка в другой оболочке. Ой, уже не одного.
В смысле? Если я не пользуюсь штатной аудиосистемой, то она перестанет быть штатной? Хорошо, для фанатов строгости могу её отключить. Всё, теперь она точно-точно не штатная?


Ну, собственно, если вы ей просто не пользуетесь — штатная. Если она не работает — то она либо поломана (если так не задумано), либо уже не штатная (если так и надо).

Сорян, я не профессиональный разработчик под Windows, и не знаю от корки до корки всю её документацию.


Т.е. рекомендации, касающиеся вснепременнейшей установки программ в ProgramFiles, а также содержащие ласковое порицание всех, кто устанавливает что-то в хомяк, вы не видели? И спецификацию «модели безопасности NT», в которой явно написано, что из-за пределов ProgramFiles ничего запускать нельзя, тоже не читали? Может быть, потому, что обоих документов не существует в природе, а «разработчикам пора уже что-нибудь прочитать» — просто пафос, ничем не обоснованный?

Проверяли то где? Я в Cinnamon, вы наверняка в другой оболочке. Ой, уже не одного.


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

Может и видел. Не помню я. Давно всё это было. Когда то я ковырял Windows до уровня своих сборок с тщательным выпиливанием ненужного и защитой оставшегося своей цифровой подписью, что по факту делало дистрибутив неотличимым от оригинального в плане работы, в отличии от кучи говносборок.
И спецификацию «модели безопасности NT», в которой явно написано, что из-за пределов ProgramFiles ничего запускать нельзя, тоже не читали?

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

Да, потом прочитал. Окей, уже две среды нарушают установленное вами поведение, не считая mc. Сколько примеров вам ещё нужно, чтобы доказать, что Linux к нынешнему времени не отличается от Windows в плане «Скачал архив с программой, распаковал и запустил»?
Может и видел


Ну, в общем, давайте сойдемся во мнении, что, может быть, и видели, но оно давно уже устарело. В определенный момент майки действительно достаточно назойливо пытались продвигать ProgramFiles как единственное место для установки программ (забыли только в /usr/bin переименовать, тогда бы точно взлетело), и даже была где-то когда-то дефолтная политика с запретом на исполнение в хомяке. Только времена эти ушли, микрософт сдался, и вышеупомянутые рекомендации, равно как и политики, канули в Лету. Ставить в хомяк совершенно не порицается на данный момент, в принципе, даже понятно, почему.

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


Ну, старенький документ, очень старенький. Стоит признать, что с тех далеких пор (2009 год) майки сильно подтянулись, стали лучше. И даже в документе я прямого упоминания «ставить только в Program Files» не нашел.

Собственно, главная проблема Program Files в моем понимании — как раз и состоит из комбинации «путь-от-диска» + «диск не бесконечен». Ну, те. ProgramFiles таки рождены ровно в пределах системного диска. Оно и хорошо бы, например, если место поджимает, подмонтировать туда же еще какой диск — ан нет, это очень плохо работает на винде.

Окей, уже две среды нарушают установленное вами поведение, не считая mc. Сколько примеров вам ещё нужно, чтобы доказать, что Linux к нынешнему времени не отличается от Windows в плане «Скачал архив с программой, распаковал и запустил»?


Ну ладно-ладно. Один всего нюанс остался — права доступа. Tar-енные архивы rwx сохраняют, а те же зазипованные и зараренные — нет. Ну и, собственно, с fat32 раздела гарантированно не запустите. И с флешки — тоже сомнительно (хотя дефолты могут плавать). А в остальном, как бы я ни расстроился от этого, да, бубль-клик теперь общая проблема. Так и хотелось сказать «А из-за кого? И кто в этом виноват...» Но ладно, не буду.
и даже была где-то когда-то дефолтная политика с запретом на исполнение в хомяке

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

Да да, не пугать пользователя UAC.
Ну, старенький документ, очень старенький.

Но тем не менее не потерял актуальности. Можно прямо сейчас настроить по нему десятку, с небольшими изменениями, и всё будет работать как там и задумывалось, система будет защищена от вирусного поражения и всяких там шифровальщиков практически на 100%.
И даже в документе я прямого упоминания «ставить только в Program Files» не нашел.

Плохо читали. Очевидно, если настроить систему по протоколу, то ставить куда либо ещё не имеет смысла, так как оттуда будет запрещён запуск.
Оно и хорошо бы, например, если место поджимает, подмонтировать туда же еще какой диск — ан нет, это очень плохо работает на винде.

Вот не знаю, куда монтировать? В Program Files? Или его 32 битный аналог?
Да и в Linux я например не стал бить диск, ибо чёрт его знает, где мне место понадобится. Сложно это.
Как по мне, так самое простое решение — купить диск с запасом. Вот у меня NVME на 512 гиг, и мне их с головой хватило на систему, пяток игрушек, и прочие радости жизни. Тяжёлые файлы, к которым не нужен быстрый доступ, были перенесены на другие диски стандартными средствами, через вкладку «Расположение».
Tar-енные архивы rwx сохраняют, а те же зазипованные и зараренные — нет

Ну так по умолчанию запуск под виндой разрешён. Впрочем, для любителей потаскать права есть родной wim.
Да да, не пугать пользователя UAC.


Ну да, и «модель безопасности NT» именно об этом и говорит: «не пугать пользователя UAC». Остального не говорит.

система будет защищена от вирусного поражения и всяких там шифровальщиков практически на 100%.


Ай, неправда ваша! Совершенно недостижимо ведь!

Плохо читали. Очевидно, если настроить систему по протоколу, то ставить куда либо ещё не имеет смысла, так как оттуда будет запрещён запуск.


Совершенно неочевидно, как то, что не имеет смысла, так и то, что именно оттуда будет запрещен запуск. Непонятно, почему вы не можете выделить какую-то еще одну папку для складывания программ, например. Могу даже обосновать, зачем: предположим, у вас в конторе есть куча самописного софта, который нужно куда-то деплоить в соответствии с внутренними политиками. Очевидно же, с учетом механизмов деплоя, что собственный софт, регулирующийся собственными политиками с самописным деплоем, есть некоторый смысл хранить отдельно — хотя бы для упрощения управления деплоем и заради отсутствия необходимости согласовывать свои политики с теми системными политиками, которые регулируют Program Files. Да элементарно, при обновлении системы вполне себе можно на грабли с изменением политик налететь. Просто сложите внутренние программы в отдельную папочку — и будет всем счастье.

Вот не знаю, куда монтировать? В Program Files? Или его 32 битный аналог?


Это, очевидно, от битности софты зависит. Оно бы хорошо симлинками вообще разрулить — но с исполняемым софтом симлинки ведут себя из рук вон…

Да и в Linux я например не стал бить диск, ибо чёрт его знает, где мне место понадобится. Сложно это.


Порядок — это всегда сложно…

Как по мне, так самое простое решение — купить диск с запасом.


Так точно: просто купи!

Ну так по умолчанию запуск под виндой разрешён.


Это плохо(((
Ну да, и «модель безопасности NT» именно об этом и говорит: «не пугать пользователя UAC». Остального не говорит.

Забавно, откуда вы это вывели?
Ай, неправда ваша! Совершенно недостижимо ведь!

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

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

У меня есть дополнительный жёсткий диск. Куда мне его монтировать?
Забавно, откуда вы это вывели?


Ну, например, оттуда, что мне тут неоднократно указывали на «модель безопасности NT, которая запрещает запуск извне Program Files». При этом спецификацию так и не привели, а само утверждение очевидно абсурдно, хотя бы по причине наличия устоявшейся практики, явно ему противоречащей. Поэтому я и подумал, что если хочется какую-то свою фантазию подкрепить якобы существующим документом для пущей важности и убедительности, нужно использовать фразу «модель безопасности NT». Нет?

Понимаете, я не против формулировки «запуск извне Program Files противоречит разумным политикам безопасности» и даже «запуск извне Program Files противоречит здравому смыслу». Однако подмена явно выраженной коннотации «в моих, вроде бы, верных рассуждениях о том, как это должно работать» на давление авторитетом вроде «противоречит модели безопасности NT» — ну, такой себе прием, с душком.

Сарказм это хорошо, когда он здоровый.


К сожалению, это не сарказм. 100%-ная безопасность недостижима.

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


Ну вот с этим выделением папки как таковой проблем нет на обеих системах. А вот «тиражировать» это изменение на Windows-системах несколько геморройней. Вся суть удобства линуксовой FHS в неизменности путей на разных физических системах. Т.е. «где что лежит физически» регулируется на уровне ядро/ФС, и по этому причине хорошо работает. На прикладном уровне этот пласт «приседаний» вида «определи, на каком диске оно лежит» отсутствует. Он не в принципе отсутствует, а на прикладном уровне отсутствует, т.к. расположен ниже него и надежно от оного абстрагирован.

У меня есть дополнительный жёсткий диск. Куда мне его монтировать?


Ну, собственно, на виндовсе — некуда и незачем. А симлинки так себе работают.
100%-ная безопасность недостижима.

С этим вроде бы никто не спорил.
А вот «тиражировать» это изменение на Windows-системах несколько геморройней.

В чём тут отличие? У меня есть два диска и две системы, одна Windows, другая Linux. В чём отличие добавления нового в этих системах? И там и там мне придётся решать вопросы, куда диск будет размещён, какие файлы там будут лежать, как их туда перемещать.
Ну, собственно, на виндовсе — некуда и незачем.

А с Linux, а с Linux то как?
В чём тут отличие? У меня есть два диска и две системы, одна Windows, другая Linux. В чём отличие добавления нового в этих системах? И там и там мне придётся решать вопросы, куда диск будет размещён, какие файлы там будут лежать, как их туда перемещать.


Отличие проявляется в том, на каком уровне вы эти проблемы решаете. На единичной машине разницы да — никакой. А теперь представьте парк из 50 машин. В линухе проблема решается исключительно системным администратором, который распределяет, как использовать ресурсы, доступные на машине. Весь уровень приложения от этих деталей абстрагирован, на уровне приложения никакой специфики уровня машины не существует. Если приложение хочет «насрать в хомяк», оно совершенно законно это делает по ссылке ~/куда/срать или, если предпочитает полные пути, /home/%username%/куда/срать — и это гарантировано одно и то же место, но совершенно не гарантировано, что один и тот же диск. Т.е. абсолютный путь в linux гарантирует, что приложение попадет куда надо, вот никак не промахнется, т.к. иерархия одна.

В винде абсолютный путь гарантирует… ничего. Вы можете оказаться как на соседнем диске, так и в другой папке. Или не оказаться — да хрен его знает. Поэтому фактически абсолютный путь не факт, что абсолютный, относительный — он и в Африке относительный, и на выходе все дружно приседают со специальным переменными окружения и настройками в реестре. При этом сама корректная работа с симлинками, например, не гарантируется, т.к. приложение должно уметь ходить по симлинкам. Реализация такая: симлинк — это файл с расширением .lnk. Т.е. существование рядом файла «МояОченьНужнаяПапка.lnk» и непосредственно папки «МояОченьНужнаяПапка» — ничему не противоречит, совпадения имен нет (к слову, еще одно странное решение на базе все того же расширения файла, которое теперь вылазит боком). Если приложение работает поверх устаревшего API, не умеющего в симлинки, оно просто может взять и создать недостающую папку рядом с симлинком, и просто все сломать.

Поэтому что-то сколько-нибудь критичное (Program Files, ProgramData) переносить на отдельный диск сам микрософт совершенно не рекомендует. Т.е. «оно, как бы, и можно, но не рекомендуется». И готового решения этой проблемы на уровне приложения нет, потому что это не проблема уровня приложения, а утекшая абстракция ФС.

А с Linux, а с Linux то как?


А с Linux, например, в /usr/local? Ну или пофигу куда, т.к. сама болячка «необходимость содержания отдельных ProgramFiles и ProgramFiles(86)» проистекает ровно из привычки «все свое ношу с собой», поголовного вынужденного пользования относительными путями и неумения при линковке определить, какой битности библиотеку линковать.
Ну или пофигу куда, т.к. сама болячка «необходимость содержания отдельных ProgramFiles и ProgramFiles(86)» проистекает ровно из привычки «все свое ношу с собой», поголовного вынужденного пользования относительными путями и неумения при линковке определить, какой битности библиотеку линковать.
вы себе специально грабли раскладываете?
/lib
/lib64
— это тоже от «неумения ...»
На моей системе вообще 4 каталога. Кто все эти люди?
Заголовок спойлера
image
Сами бинарники-то в /bin, все, и 32, и 64-битные…

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

Виндовый подход — положить бинарь и заставить его по относительным путям искать линкуемую библиотеку рядом с собой. Поэтому и выходит, что абы куда бинарь не положишь, ну или положишь, но только со всеми зависимостями.
я вот сперва пытался понять вашу претензию на разделение %ProgramFiles (x86)% & %ProgramFiles% — для чего привел вам пример такого же разделения библиотек в Linux — хотя и там, и там понятно, что хранить что исполняемые файлы, что библиотеки можно где угодно, просто это некие well-known пути, к-рые использовать проще, чем сопровождать каждую программу отдельной записью в PATH.
Но вот это ваше замечание меня совсем удивило. Поиск библиотек вполне можно выполнять по абсолютным путям в Windows (тот самый %ProgramFiles% либо прописанный в ветке реестра программы), по относительным (если есть такое желание разработчика программы) и по well-known путям (перечисленным в PATH).
Какой иной вариант, кроме статической линковки, вы можете предложить? И, самое забавное, как, кроме сборки каждой программы на месте, вы можете обеспечить эту статическую линковку?
Вы можете оказаться как на соседнем диске, так и в другой папке.

Но ведь это именно то, что нужно, когда программе должно быть всё равно, куда данные пишутся реально, на этот же диск или в какой-нибудь другой каталог.
Реализация такая: симлинк — это файл с расширением .lnk.

Извините, но вы отстали лет на 20. Симлинк это симлинк, работает ровно так же, как и на Linux, никакой поддержки со стороны ПО не нужно, если это ПО не отслеживает состояние кучи файлов. То что вы описали это в русскоязычной документации называется ярлыком.
Поэтому что-то сколько-нибудь критичное (Program Files, ProgramData) переносить на отдельный диск сам микрософт совершенно не рекомендует.

Причины там несколько иные. Многие файлы в этих каталогах на самом деле так сказать жёсткие ссылки для обратной совместимости, а система оперирует файлами в WinSxS (или как он там). А так как жёсткие ссылки невозможны между разными томами (как в Windows, так и Linux), то могут возникнуть казусы.
А с Linux, например, в /usr/local?

И что мне это даст, если всё место жрёт к примеру /var/lib/mysql?
Ну, тут уж сами определитесь, какой вариант вам кажется более верным.

Второй ближе всего.
Большая часть разработчиков вполне себе следует рекомендациям Microsoft. У них есть инстралятор, который просит права админа, устанавливает программу куда нужно, и впоследствии её можно без проблем запускать от пользователя, так как все настройки пишутся в каталог пользователя.
и даже специальная переменная окружения %LOCALAPPDATA% заведена для покрытия этого случая.

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

Всё так и есть. Очевидные причины этому — UAC пугает пользователей, а так как на масштабах хрома даже 0,5% уникумов это солидная пользовательская база, то было решено не пугать их и ставить в хомяк.
Разработчикам системы также стоит, видимо, прочитать собственноручно написанные гайды, и предпринять какие-то действия, чтобы дефолтные настройки системы им следовали.

Как уже заметили ниже проблема легаси. Я вот вполне себе сижу с такими настройками (и хромом не пользуюсь), но на масштабах майкрософта даже 0,1% сломанного По превращается в дикий вой всего интернета. Поэтому гайки затягивают постепенно.
Например, разработчикам Офиса почитать не дали — он отлично в хомяк встает, как влитой. За «шах и мат» считается?)))

Это печально, вне всякого сомнения. Хотя думаю у такого ПО, которое используется в крупных корпорациях, просто обязанна быть версия в виде какого-нибудь MSI с поддержкой групповых политик. Ну или я отстал от жизни, и теперь всем на всё пофиг.
Сорян за серьезную реакцию с элементами троллинга

Всё путём! Пойдём выпить чайку?
Добавим чутка серьезных мыслей: в реальной дикой природе данное поведение (все из Program Files), к сожалению, малодостижимо

Есть такая проблема. Хотя я вот у себя такое реализовал, но я не дикая природа.
«Кодить на нативных компилированных языках» станет привилегией админов локалхоста — тоже такое себе.

Так они и сейчас скорее всего админы. Не знаком с разработкой нативного софта, но мне кажется, что для всяких отладчиков так и так нужны админские права.
Не знаком с разработкой нативного софта, но мне кажется, что для всяких отладчиков так и так нужны админские права
Не нужны. Родительский процесс (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. В связи с этим, работника а) никто силой на галеру не заволакивает, б) никто к стулу не приковывает. Если люди там сидят, значит, им норм. Что не так?

В принципе, можете и дальше их оправдывать. Мне с ними не по пути. Пройду мимо.


Рад за вас, юношеско-максималистичный вы наш.

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


Про «единственно верное» — это не мои слова. Ваши скорее. Про альтернативные пути развития я ни слова не говорил, я говорил конкретно про «ужасные рабские галеры» — в них нет, по сути, ничего вопиюще-плохого. Обобщать частное представление на целое — вообще не мой конек. Это вы однозначно осуждаете «галеры» и стоите на безусловных позициях «свобода или смерть». Я человек старый, женатый, есть ребенок — я менее максималистичен и склонен рабочие места оценивать исключительно через призму личных шкурных интересов. Если по совокупности получаемых от работы профитов «галера» окажется для меня привлекательней «маленького, но гордого коллектива голодных разработчиков» — я предпочту устроиться на галеру, и не спеша грести там. Искренне не вижу, что плохого в «галерах» как сущности, что их нужно так решительно осуждать. Так можно договориться, что демократия — единственно приемлемая форма управления, безусловно превосходящая все остальные. Свят-свят.
чтобы соседняя учетка ну точно-точно, никак-никак, совсем-совсем не получила доступ

А вот тут нет никаких проблем. Исполняемые файлы могут лежать в Program Files, а данные учётной записи в профиле. И тогда при заходе из другого профиля просто попросят ввести эти учётные данные.
Собственно, в этом и, имхо, правильный подход — дать рабочий инструмент и некие разумные умолчания. Инструмент, в принципе, достаточно рабочий, а вот с разумностью умолчаний, пока что, полный швах у майков.

Согласен, проблемы в умолчаниях, которые нельзя поменять по причинам совместимости.
Так что давайте по кофию!

По кофию!
А вот тут нет никаких проблем. Исполняемые файлы могут лежать в Program Files, а данные учётной записи в профиле. И тогда при заходе из другого профиля просто попросят ввести эти учётные данные.


Проблема только одна: сама концепция пользовательских профилей в широком применении на винде появилась достаточно поздно. В домашних системах, емнип, с Windows XP, притом в достаточно куцем варианте. Полноценные профили — это уже ажно Windows7. Притом, откуда эти самые профили «завезли» тоже понятно. И вот дальше чужеродную nix-философию стали натягивать на то, что уже накопилось, стараясь не поломать то, что уже работает. Короче, ситуация патовая в хлам.

Ну а, собственно, по поводу того, как заставить софтину, не рассчитанную на работу из ProgramFiles, работать внутри хомяка — есть workdir, т.е., по сути, проблема, в принципе, решаема. Но удобного инструмента под это нет. И не будет, по очевидным системам.

Согласен, проблемы в умолчаниях, которые нельзя поменять по причинам совместимости.


И еще одна вещь — периодическая невозможность использовать разумные настройки в рамках сложившихся условий. Всегда найдется какая-нибудь ну-очень-важная-фигня, которая откажется работать в условиях разумных ограничений прав.
с Windows XP, притом в достаточно куцем варианте.

В смысле в куцем? Не припомню никаких отличий между XP и последующими версиями, кроме UAC, который суть костыль.
И вот дальше чужеродную nix-философию стали натягивать на то, что уже накопилось

Это, как бы ядро NT с самого своего зарождения приспособлено для работы в многопользовательской среде, это одно из требований к его разработке. И проблем с профилями никаких нет.
В смысле в куцем? Не припомню никаких отличий между XP и последующими версиями, кроме UAC, который суть костыль.


Ну, собственно, «классика» выглядит как «у пользователя есть хомяк, за пределы которого он не может вылезти». В windows — слабо-реализуемо, хотя бы из-за особенностей иерархии файловой системы.

Это, как бы ядро NT с самого своего зарождения приспособлено для работы в многопользовательской среде, это одно из требований к его разработке. И проблем с профилями никаких нет.


Это, как бы ядро NT получило широкое пользовательское распространение именно на этапе Windows XP. 2000, NT 3,4,4.5 — таки экзотика для пользовательских компьютеров.

Ну и, собственно, проблемы с профилями таки есть. Они «текут» по дефолту.
Ну, собственно, «классика» выглядит как «у пользователя есть хомяк, за пределы которого он не может вылезти». В windows — слабо-реализуемо, хотя бы из-за особенностей иерархии файловой системы.

А что поменялось впоследствии?
Для системы с одним диском всё это работает прекрасно. А как на Linux помогает монтирование в каталоги (что доступно и на Windows) я ума не приложу.
Для системы с одним диском всё это работает прекрасно.


Ага, а для системы с несколькими — никак.

А как на 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:
Стоп-стоп, вы определитесь, речь о домашнем компе или как? Если о домашнем, то юзер сам себе админ и свободно разложит по дискам свои кинчики и игрушечки. И на отдельных дисках их держать удобнее, чем все смонтированное в один хомяк. Хотя бы из соображений резервирования и переноски на другие места.

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

Если о домашнем, то в большинстве случаев у него один диск.
Не, ну если это юзер-гик, он может докупать диски по мере необходимости в хранилищах.
Ну да, как я и сказал, меньшинство.
В суровые 90-е меньшинством были те, у кого 1 диск…
Вы, видимо, молоды… )))
И на отдельных дисках их держать удобнее, чем все смонтированное в один хомяк.


Ай не факт, чесслово!

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


Ну не так все просто, однако же.

Но в целом проблемы решаемы — ага.
К тому же расположение «хомяка» на системном диске (а в штатных инструментах установки, вроде, нет возможности без приседаний унести «хомяк» в другой раздел

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

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

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

Я не исключаю вероятности, что программы написаны некорректно (условно вместо %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-… дискам — я вижу их все в одной папке Видео. Тут уже вообще без разницы, как происходит монтирование файловых систем/разделов:
Библиотеки


Библиотеки

Фича откровенно не взлетела и пылится сейчас где-то на задворках интерфейса. Хотя была весьма интересной, если бы её допилить.
Да, конечно, 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-… дискам — я вижу их все в одной папке Видео. Тут уже вообще без разницы, как происходит монтирование файловых систем/разделов


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

Замечу, что ветка пользователя хранится в его домашнем каталоге.
К тому же один хрен у вас останется некоторое количество программ, которые будут упорно «испражняться» по прямому пути в C:\Users\%userName%, и это вам уже не победить

Рецепт победы прост — симлинк с того пути на его актуальное положение. Работает для 99,99% софта. Syncthink к сожалению отказывается работать с симлинками и точками соединения, но пока лично я его использую для синхронизации пары каталогов, которые легко помещаются на один диск.
Рецепт победы прост — симлинк с того пути на его актуальное положение. Работает для 99,99% софта.


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

Ну, короче, такая себе победа. «С такими друзьями враги не нужны». Да и вообще, штатный механизм системы, который работает для 90% софта «из коробки», для 9,99% софта требует подпирания костылем, а для оставшихся не работает вообще. Такое себе. Вы же должны признать, что с этой частью в винде не все в порядке.
А симлинкать придется каждый конкретный косячный путь.

ХЗ, не встречал косячных прог, но этих путей не так уж и много. Сейчас посчитал, у меня перенесено целых 5 путей (Музыка, Видео, Документы, Загрузки, Изображения). Из неперенесённого остались только Сохранённые игры, куда по наивняку сложила сейвы целая одна игрушка.
А некоторые программы при обновлении любят удалить целиком папку с предыдущей инсталляцией (читай, ваш симлинк) и установиться заново.

Покажите мне программу, которая удаляет целиком каталог документов, или там музыки.
Вы же должны признать, что с этой частью в винде не все в порядке.

Не идеально. Хотя очевидно, проблема в разработчиках (да, опять), которые не осилили переменные пути.
Но ваши проценты отнюдь неверны. Лично я у себя не нашёл ни одного артефакта, хотя никаких симлинков не создавал.
ХЗ, не встречал косячных прог


Счастливчик…

Собственно, подскажу, где искать. Берете любую прогу, которая была написана под 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 (подскажу, в дикой корпоративной природе его много).
Берете любую прогу, которая была написана под WinXP

Прямо любую? Вот я пользуюсь DM2 для пары сочетаний клавиш. И никуда она не промахивается, кроме своего конфига, который винда перенаправляет в профиль. Что я опять сделал не так? Любая программа уже не любая?
и именно туда было принято складывать пользовательскую фигню.

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

Я их вроде даже перечислил.
Т.е. я беру, профиль программы

Что такое «профиль программы» и зачем синкать его? Программа обычно хранит свои настройки внутри определённого каталога, например, Документы. И, перенеся этот каталог, вы автоматически переносите все настройки всех программ, хранящихся там.
Ну а если вы вручную что-то там копируете и симлинкаете, то вы сами виноваты как в бардаке, который устроили, так и в его последствиях в виде периодически отваливающихся программ.
Есть «C:\Users\%username%», есть "%userprofile%", есть "%system%\Documents and Settings\%username%" — тысячи их. И все они по дефолту ведут в одно и то же место.

Я не знаю, каким нужно быть наркоманом, чтобы хардкодить какие-то пути. Все нормальные программы используют %userprofile%, который всегда ведёт в профиль, как ни странно.
Преимущества хранения, например, настроек сессии и всех юзеро-специфичных настроек софты в домашней папке пользователя над тем же общесистемным реестром, равно как и недостатки подхода, тоже представляю.
Представляете, но ошибаетесь. Пользовательские настройки хранятся в кусте реестра пользователя, к-рый хранится в профиле пользователя (ntuser.dat).
Начиная от единой точки входа в рабочее пространство… — плохо заперли).
извините, но тут очень много «воды». Если вам нужно ограничить пользователя на станции, то, чаще всего, это либо терминальный сервер, либо ПК общего доступа. в обоих случаях с помощью групповых (AD) или локальных политик вы обеспечиваете необходимое сокрытие данных. Во 2ом случае вы можете использовать еще и обязательные профили. Вот уж чего-чего, а жалоб на возможности по ограничению пользователей в корп среде я не наблюдал.
Это которое через AD? Честное слово, имхо, немного «из пушки по воробьям».
используйте локальные политики. Просто без AD вы заводите пользователей вручную — при создании и профили можете перенаправить.
«Хомяк» пользователя — это его реальное рабочее пространство. Сейчас все дружно на SSD переползают, они дорогие, например.
еще раз — сформулируйте реальный кейс. а то у вас смешение «дом»-«работа». Дома чаще всего и linux, и windows ставят все-на-один-раздел — просто потому, что end user не будет там заморачиваться, сколько ему на swap, сколько на boot и сколько на root «отрезать». а на работе — folder redirection if required.
А само предложение «оставьте хомяк где есть, а фильмы в явную храните на другом диске» просто делит на ноль саму концепцию «рабочего пространства пользователя». Зачем отдельная установленная папка вообще, если данные пользователя равномерным слоем размазаны по 100500 дисков и эта взаимосвязь никак не прослеживается автоматически?
Все пользовательские данные в пределах «хомяка» — это прекрасно же. Элементарно забекапить — просто натравить dd на хомяк пользователя

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

Если компьютер персональный, то там все диски — хомяк.

Если он семейный, то какой смысл изолировать фильмы (фотографии) от других пользователей.

Бекапить весь хомяк и одновременно рекомендовать хранить там фильмы — ну, такое…
В винде есть «ряд нюансов».

В принципе, разрешимых.
Ага, а для системы с несколькими — никак.
А в чём проблема настроить? В винде корень системного диска недоступен для записи юзерам, но доступен на чтение (как и в линукс).

Но для удобства корни других разделов доступны в r/w. Сделайте просто настройки прав на каждый корень, и будет как в линуксе.
Есть ещё маленький секрет — диски в Windows можно монтировать в каталоги. Замещать системные каталоги так не следует, но для любого пользовательского вполне себе работает.
Есть ещё маленький секрет — диски в Windows можно монтировать в каталоги. Замещать системные каталоги так не следует, но для любого пользовательского вполне себе работает.


Ну вот я и говорю — «есть-то оно есть, но работает не везде, не со всем, и вообще использование, как говорится, сопряжено...» Т.е., вроде как, механизм и есть, и вроде как не совсем рабочий…
В смысле? Всё там прекрасно работает, отличие от Linux только в том, что это не по умолчанию.
Но для удобства корни других разделов доступны в r/w. Сделайте просто настройки прав на каждый корень, и будет как в линуксе.


Ну да, «повторите операцию N раз» и «не забывайте повторять при каждом подключении диска».
Права на все несъёмные диски можно настроить 1 раз при установке системы.

Когда юзер-не-админ втыкает флешку в linux, она ему доступна на чтение? На запись? А если он втыкает usb-диск, чем-то это принципиально отличается?
Проблема только одна: сама концепция пользовательских профилей в широком применении на винде появилась достаточно поздно. В домашних системах, емнип, с Windows XP, притом в достаточно куцем варианте. Полноценные профили — это уже ажно Windows7
Ещё в NT4 можно было сесть за любой компьютер в сетке, залогиниться доменной учёткой и получить свой рабочий стол, данные и программы. Далее была Win2000, а XP та же 2k с цветастыми непрямоугольными кнопками.

В XP профили есть в полной мере.

Проблема домашних систем от MS в том, что домашние пользователи все поголовно сидят под админом, поэтому профили и их изоляция не имеет смысла. Это стали затыкать костылями типа UAC и бредовыми настройками ACL, что прав админа недостаточно, чтобы лезть в систему, права SYSTEM выше.

Ну, собственно, «классика» выглядит как «у пользователя есть хомяк, за пределы которого он не может вылезти». В windows — слабо-реализуемо, хотя бы из-за особенностей иерархии файловой системы.
Ээээ… Не понял. Уберите у юзера права админа и он будет вечно сидеть в своём хомяке.
Ээээ… Не понял. Уберите у юзера права админа и он будет вечно сидеть в своём хомяке.

Кажись он про то, что у дополнительных жёстких дисков по умолчанию можно писать в корень. То есть в каком-нибудь ноутбуке с 2 дисками на втором будет свалка всех пользователей, если не приложить усилий к наведению порядка.
Ты ж мой умница! Посмотрите, все с первого раза понимает!))))
Опять же, если это семейный ноутбук, ну будет общая свалка файлов мужа и жены на одном диске, в чём проблема? Вы хотите их заставить изучать права и монтирование? Так вы ОСь не продадите.

А кому надо, зайдут в свойства и выставят разрешения, делов на 2 минуты. Кинут юзерам на рабочие столы ярлыки на разрешённые папки на втором диске, чтобы не искали, и вся настройка.
Опять же, если это семейный ноутбук, ну будет общая свалка файлов мужа и жены на одном диске, в чём проблема? Вы хотите их заставить изучать права и монтирование? Так вы ОСь не продадите.


Если это «семейный ноутбук», до «свалки файлов мужа и жены на одном диске» обычно не доходит, у них учетка одна. «А как же разные профили в одноклассниках» — спросите вы? Голь на выдумки хитра! — остроумно отвечу я вам. — У них разные браузеры!

А кому надо, зайдут в свойства и выставят разрешения, делов на 2 минуты. Кинут юзерам на рабочие столы ярлыки на разрешённые папки на втором диске, чтобы не искали, и вся настройка.


Не, не кинут. В чужой хомяк не смогут, потому что туда прав писать нету. Просто заставят заучить «D:\Разное\Фильмы\ФильмыЖены\Свадьба\2019».

Просто это совсем уже какие-то крайние случаи демократии, этим конкретным людям ни FHS, ни распределение прав не нужны. Да и понятие «многопользовательская система» для них настолько далеко, что вот на их случай все равно никто ничего не предусматривал.
У них разные браузеры!

Да не, один хром с двумя профилями. Ибо нет браузера, кроме хрома, и гугл пророк его.
Обижаете! А как же «трусы»? А куда «Мейл.Браузер» дели? Больше хромов богу хромов же!

А профили — это еще знать надо, что они есть. Это сложно.
Не, не кинут. В чужой хомяк не смогут, потому что туда прав писать нету
Так один из юзеров в этом сценарии так или иначе админ. Он и права настроит, и ярлыки бросит.
А теперь предположим, что семья большая, пусть будет 50 человек. И надо каждому на рабочий стол ярлыки разложить. А системный диск — маленький, поэтому половина профили на другие диски смигрировала, а остальные — кто симлинков понавтыкал, кто еще как изголялся.

Была бы иерархическая ФС — проблем бы не было: просто циклом пробегаем по подкаталогам /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 — неделимое) операция — операция, которая либо выполняется целиком, либо не выполняется вовсе; операция, которая не может быть частично выполнена и частично не выполнена.» В случае с правами, очевидно, атомарным может считаться право, которое «не может быть частично выполнена и частично не выполнена». Единичка в бите «исполнение» и отсутствие таковой в бите «чтение» означает именно ситуацию «частично право есть», т.е. оно как будто бы и есть, и при этом ни разу не выполняется. Налицо нарушение принципа атомарности.