Автор не программист, и тем более в такой критичной области у него нет прав что-то даже просто кодить, а тем более вводить новую политику какого-то санитайзинга. Он сделал, что мог.
Есть ненулевые шансы, что санитайзинг был предложен как решение его тикета, но это уже надо иметь инсайдера, чтобы узнать.
Ну у меня вызывает вообще вся пачка RFC вопрос, почему баги старых версий не правились годами и десятилетями; Errata начали делать только где-то начиная с 2000-х, и то правленых текстов так и нет. И RFC919, как и ещё десятки прочих, весь надо переписывать было уже как только отменили классы сетей. Заодно и это бы пофиксили. А ляпов там всегда было выше крыши - вспоминаем Telnet, который по исходному описанию в принципе не мог работать, пока не написали отдельный RFC про защиту от зацикливания между DO/WILL и DONT/WONT :)
Вы чрезмерно, даже катастрофически упростили ситуацию. Во-первых, проигнорировали такие формы, как "полагать" (парное к "положить"), "разлагать" (к "разложить" в другом смысле), "прилагать"... Во-вторых, формы с -кладывать, конкретнее, с этим -ыва-, сильно вторичны: исходно пары выглядели как скласть - складать, и т.п.; -ыва- это суффикс вымершего многократного вида (от которого остались "захаживать" и ещё очень немного аналогичных примеров); это сейчас 2 вида глагола, а был период, когда их было 4. В-третьих, как раз общая парадигма, которая реализуется для большинства глагольных основ, что есть базовый несовершенного вида, к нему без изменения добавляются приставки, создавая глаголы совершенного вида, а уже от них с каким-нибудь суффиксом - снова несовершенного. И вот именно с этим случаем этот общий принцип почему-то был намеренно сломан, "класть" изолирована (где "скласть", "покласть"?) С этой парой корней и всеми производными всё непросто, и не надо упрощать с искажением.
drone verb [ I ] to make a low, continuous noise: The radio droned in the background while we talked. To drone on is to talk in a low voice that does not change and is considered boring.
В юниксе создание симлинка доступно каждому, и все средства, которым важно хоть какое-то секьюрити за пределами прав одного пользователя, обучены проверять их при операциях, где может сработать раскрытие симлинка, есть ключи вроде O_NOFOLLOW для атомарной проверки факта симлинка при переходе по части пути. Сам факт симлинков и проблемы с ними описаны в букварях.
В Windows создание симлинка - привилегированная операция (непонятно, почему), средств не перейти по симлинку, если нельзя - нет, про проблему 90+% пишущих под неё, наверно, не знает, часть не знает про существование симлинков в принципе.
А у кого есть доступ к железу, есть доступ вообще ко всему :)
Если железо его допускает и цена на операцию подъёмная. В случае Intel SGX, вам, например, денег точно не хватит, чтобы найти, как в конкретном процессоре чего доработать напильником прямо на кристалле, чтобы добраться до памяти анклава в нешифрованном виде:)
Угу. Ну вот в том и дело, что когда речь идёт про CPU, доступ к диску и т.п., мы можем обеспечить какие-то гарантированные объёмы ресурса простейшими локальными методами, а если про сеть - то на это требуется обеспечение по всему пути до каждого ремота. А так как IntServ начали завозить, потом вывезли обратно и больше не завезут (локальные сети на IB и прочее за прайс x20 не считаю), то весь рассказ ТС про "гарантии стабильности и полную свободу" - уже даже не маркетинговое враньё.
Вот против такого и придумали Intel Software Guard Extensions (не знаю насчёт адекватных аналогов у остальных), есть на программном уровне варианты шифровать все данные и обрабатывать в шифрованном виде (чисто алгоритмически описано у Шнайера), наверняка ещё что-то придумали, я только поверхностно знаю. Но у Intel и AMD сейчас даже память, занятая виртуалками, может проходить шифрование данных, чтобы при случайной её выдаче соседям или хозяйской системе они ничего не прочитали. Диск может быть запаролен, а пароль вычисляться при старте на основании данных лукапа куда-то извне. И прочая и прочая.
В сумме это не даёт 100%, конечно, но на порядки резко усложняет подглядывание нечестным админом.
И тут возникает вопрос - а как при виртуализации чувствует себя этот кэш: не сможет ли один VDS начать бесконтрольно его использовать, мешая остальным?
Лучше считать, что при переключении виртуалок на конкретном ядре кэш чистится в ноль. (Это может быть и явным действием для защиты от проблем типа Meltdown/Spectre, и неявным за счёт того, что другой гость начинает активно использовать кэш, и тогда данные прежнего вымываются.)
А вот если есть shared L3 общий на все ядра - то зависит от плотности использования, и тут надо смотреть на политики ведения этого кэша...
Была такая технология в начеле 10-х (и вроде как, и сейчас есть) - Single Root IO Virtualization (SR-IOV).
Спасибо, я в 2011 её щупал. Основной вариант разделения по MAC, но можно и как-то ещё извратиться. В гостя выставляется интерфейс типа обычной сетевухи, но попроще. Но:
а потому вероятность стать узким местом при DDOS для него невелика.
Кабель всё равно один. И та часть карты, что принимает и раскладывает по гостям, одна. Я именно про это говорю.
У Кена вообще замечательнейший блог...
Лучше forced-commands-only, при этом в authorized_keys записаны команды и их легко верифицировать.
Но Паркинсон при этом утверждал, что принцип Питера не работает.
https://n-t.ru/ri/pr/zp44.htm
Согласно последнему постановлению ~ВЦСПС~, немного не так:
002D;HYPHEN-MINUS;Pd;0;ES;;;;;N;;;;;
то есть он одновременно и минус, и дефис.
По отдельности они как раз есть в юникоде.
Автор не программист, и тем более в такой критичной области у него нет прав что-то даже просто кодить, а тем более вводить новую политику какого-то санитайзинга. Он сделал, что мог.
Есть ненулевые шансы, что санитайзинг был предложен как решение его тикета, но это уже надо иметь инсайдера, чтобы узнать.
Да, метка "перевод" стоит на статье.
Это перевод. Считаете, нужно было решить, что на хабре все умеют в ASCII, и выкинуть это?
Ну у меня вызывает вообще вся пачка RFC вопрос, почему баги старых версий не правились годами и десятилетями; Errata начали делать только где-то начиная с 2000-х, и то правленых текстов так и нет. И RFC919, как и ещё десятки прочих, весь надо переписывать было уже как только отменили классы сетей. Заодно и это бы пофиксили.
А ляпов там всегда было выше крыши - вспоминаем Telnet, который по исходному описанию в принципе не мог работать, пока не написали отдельный RFC про защиту от зацикливания между DO/WILL и DONT/WONT :)
Вы чрезмерно, даже катастрофически упростили ситуацию. Во-первых, проигнорировали такие формы, как "полагать" (парное к "положить"), "разлагать" (к "разложить" в другом смысле), "прилагать"... Во-вторых, формы с -кладывать, конкретнее, с этим -ыва-, сильно вторичны: исходно пары выглядели как скласть - складать, и т.п.; -ыва- это суффикс вымершего многократного вида (от которого остались "захаживать" и ещё очень немного аналогичных примеров); это сейчас 2 вида глагола, а был период, когда их было 4. В-третьих, как раз общая парадигма, которая реализуется для большинства глагольных основ, что есть базовый несовершенного вида, к нему без изменения добавляются приставки, создавая глаголы совершенного вида, а уже от них с каким-нибудь суффиксом - снова несовершенного. И вот именно с этим случаем этот общий принцип почему-то был намеренно сломан, "класть" изолирована (где "скласть", "покласть"?)
С этой парой корней и всеми производными всё непросто, и не надо упрощать с искажением.
https://dictionary.cambridge.org/dictionary/english/drone :
Хм, а яндекс-мессенджером точно пользуются три калеки?
Я думал, при всех прочих там не менее пяти миллионов пользователей будет.
В юниксе создание симлинка доступно каждому, и все средства, которым важно хоть какое-то секьюрити за пределами прав одного пользователя, обучены проверять их при операциях, где может сработать раскрытие симлинка, есть ключи вроде O_NOFOLLOW для атомарной проверки факта симлинка при переходе по части пути. Сам факт симлинков и проблемы с ними описаны в букварях.
В Windows создание симлинка - привилегированная операция (непонятно, почему), средств не перейти по симлинку, если нельзя - нет, про проблему 90+% пишущих под неё, наверно, не знает, часть не знает про существование симлинков в принципе.
Что-то это таки должно значить.
Вообще отношение хозяин/гость ортогонально "кольцу команд" (слишком x86 термин, ну да пусть).
Какой был процессор, в каком режиме работала kvm (как минимум, EPT/NP или shadow tables), какая битность систем, были ли вложенные гости?
Если железо его допускает и цена на операцию подъёмная. В случае Intel SGX, вам, например, денег точно не хватит, чтобы найти, как в конкретном процессоре чего доработать напильником прямо на кристалле, чтобы добраться до памяти анклава в нешифрованном виде:)
Угу. Ну вот в том и дело, что когда речь идёт про CPU, доступ к диску и т.п., мы можем обеспечить какие-то гарантированные объёмы ресурса простейшими локальными методами, а если про сеть - то на это требуется обеспечение по всему пути до каждого ремота. А так как IntServ начали завозить, потом вывезли обратно и больше не завезут (локальные сети на IB и прочее за прайс x20 не считаю), то весь рассказ ТС про "гарантии стабильности и полную свободу" - уже даже не маркетинговое враньё.
Вот против такого и придумали Intel Software Guard Extensions (не знаю насчёт адекватных аналогов у остальных), есть на программном уровне варианты шифровать все данные и обрабатывать в шифрованном виде (чисто алгоритмически описано у Шнайера), наверняка ещё что-то придумали, я только поверхностно знаю. Но у Intel и AMD сейчас даже память, занятая виртуалками, может проходить шифрование данных, чтобы при случайной её выдаче соседям или хозяйской системе они ничего не прочитали. Диск может быть запаролен, а пароль вычисляться при старте на основании данных лукапа куда-то извне. И прочая и прочая.
В сумме это не даёт 100%, конечно, но на порядки резко усложняет подглядывание нечестным админом.
А вы не пробовали возить товары в магазинчик за углом не на Ан-22? И с каких это пор Spring Boot тождественно Java?
Кстати, какую именно память вы меряли? Их несколько.
Что означает выбор вами в сравнении менее прожорливого фреймворка, не более того.
У меня с реально равным по сути и объёму кодом получалось от полутора раз, зависит от данных.
Утверждения про прожорливость Java отстают лет на 15. И в любом случае она будет менее прожорлива, чем Python на тех же задачах.
Утверждения про проблемы с поддержкой - я не понял, к какому именно языку они относятся.
Лучше считать, что при переключении виртуалок на конкретном ядре кэш чистится в ноль. (Это может быть и явным действием для защиты от проблем типа Meltdown/Spectre, и неявным за счёт того, что другой гость начинает активно использовать кэш, и тогда данные прежнего вымываются.)
А вот если есть shared L3 общий на все ядра - то зависит от плотности использования, и тут надо смотреть на политики ведения этого кэша...
Спасибо, я в 2011 её щупал.
Основной вариант разделения по MAC, но можно и как-то ещё извратиться. В гостя выставляется интерфейс типа обычной сетевухи, но попроще. Но:
Кабель всё равно один. И та часть карты, что принимает и раскладывает по гостям, одна. Я именно про это говорю.
Win12?