The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]

05.12.2018 12:08  В Kubernetes 1.13 устранена критическая уязвимость, позволяющая поднять свои привилегии

Состоялся релиз платформы оркестровки контейнеров Kubernetes 1.13, позволяющей как единым целым управлять кластером Linux-контейнеров, созданных с использованием таких инструментариев как Docker и rkt. В новой версии устранена критическая уязвимость (CVE-2018-1002105), позволяющая любому пользователю получить полный контроль за кластером изолированных контейнеров. Проблема также устранена в обновлениях 1.10.11, 1.11.5 и 1.12.3.

Для совершения атаки достаточно отправить через API специально оформленный запрос определения доступных бэкендов (discovery-запрос). Из-за ошибки данный тип запросов оставляет открытым сетевое соединение, что позволяет использовать сервер API (kube-apiserver) в качестве посредника для отправки запросов любому бэкенду, воспользовавшись соединением, установленным с сервером API. Соответственно, перенаправляемые через подобные соединения запросы будут обработаны бэкендом как внутренние запросы от сервера API, отправленные с использованием параметров аутентификации сервера API.

По умолчанию все аутентифицированные и неаутентифицированные пользователи Kubernetes имеют возможность отправки через API discovery-запросов, которых достаточно для совершения атаки. Таким образом, любой непривилегированный пользователь Kubernetes, имеющий доступ к API, может получить полный контроль за всей инфраструктурой, например, отправив запрос для выполнения своего кода на хосте. Кроме получения контроля за инфраструктурой Kubernetes уязвимость также может применяться для целевых атак на клиентов через манипуляцию размещёнными в облаке клиентскими сервисами.

Проблема проявляется во всех версиях Kubernetes, начиная с релиза 1.0. Всем администраторам Kubernetes рекомендуется срочно обновить свои системы до актуальных выпусков, а также провести аудит системных логов на предмет возможной вредоносной активности. В качестве обходного метода защиты от атак со стороны неавторизированных пользователей можно запретить анонимный доступ к API при помощи опции "--anonymous-auth=false" и отозвать права на выполнение операций exec/attach/portforward. Отдельно отмечается, что в логах Kubernetes атака с использованием неавторизированных запросов никак не фиксируется, поэтому определить была ли компрометация можно лишь по косвенным признакам.

Дополнение: опубликован рабочий прототип эксплоита.

Основные новшества Kubernetes 1.13:

  • Стабилизирован интерфейс CSI (Container Storage Interface), позволяющий создавать плагины для поддержки различных систем хранения. CSI предоставляет единый интерфейс для выделения места, прикрепления и монтирования хранилищ, дающий возможнсть поставлять плагины для интеграции с различными службами хранения без необходимости внесения изменений в кодовую базу Kubernetes;
  • По умолчанию задействован DNS-сервер CoreDNS, развиваемый под эгидой организации Linux Foundation. CoreDNS написан на языке Go и примечателен гибкой архитектурой на базе подключаемых плагинов. Например, через плагины реализованы такие специфичные функции, как обнаружение сервисов Kubernetes, накопление метрик для системы мониторинга Prometheus и интеграция с системой хранения конфигурации etcd;
  • Стабилизирован kubeadm, упрощённый интерфейс для управления кластером Kubernetes, позволяющий выполнять такие операции как создание и развёртывание кластера на имеющемся оборудовании, настройка базовых компонентов Kubernete, подключение и удаление узлов, выполнение операций обновления;
  • Представлен экспериментальный интерфейс для создания плагинов для интеграции со сторонними системами мониторинга;
  • Стабилизирован сервис Kubelet Device Plugin Registration, предоставляющий средства для доступа к Kubelet из плагинов;
  • Стабилизирован планировщик распределения контейнеров TAVS (Topology Aware Volume Scheduling), учитывающий топологию разделов Pod (учитывает ограничения, установленные для узлов и зон);
  • Перешли на стадию бета-тестирвоания APIServer DryRun, команда Kubectl Diff и возможность использования локальных (raw) блочных устройств в качестве хранилищ постоянных данных (Persistent Volume Source).

Напомним, что код Kubernetes написан на языке Go и распространяется под лицензией Apache 2.0. Проект изначально был создан компанией Google, но затем переведён на независимую площадку, курируемую организацией Linux Foundation. Платформа позиционируется как развиваемое сообществом универсальное решение, не привязанное к отдельным системам и способное работать с любыми приложениями в любых облачных окружениях.

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

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

  1. Главная ссылка к новости (https://www.redhat.com/en/blog...)
  2. OpenNews: Выпуск Kubernetes 1.9, системы управления кластером изолированных контейнеров
  3. OpenNews: Выпуск Kubernetes 1.0, системы управления кластером изолированных контейнеров
  4. OpenNews: Уязвимость в ядре Linux, позволяющая выйти из изолированного контейнера
  5. OpenNews: Уязвимость в LXC, позволяющая получить доступ к файлам вне контейнера
  6. OpenNews: В Docker 1.12.6 устранена уязвимость, позволяющая выбраться из контейнера
Лицензия: CC-BY
Тип: Проблемы безопасности
Ключевые слова: kubernetes
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.3, A.Stahl (ok), 12:25, 05/12/2018 [ответить] [показать ветку] [···]    [к модератору]
  • +9 +/
    >Kubernetes

    Что-то про эту штуку пишут куда ни плюнь. Какие-то семинары, съезды, конференции. Баги теперь ещё.

    Это какой-то злобный маркетинг?

     
     
  • 2.4, Аноним (4), 12:27, 05/12/2018 [^] [ответить]    [к модератору]
  • +9 +/
    С разморозкой, сношают мозги уже не первый год.
     
  • 2.6, Stax (ok), 13:09, 05/12/2018 [^] [ответить]     [к модератору]
  • +5 +/
    Нет, просто она затыкает целый набор потребностей, а все альтернативы сильно уст... весь текст скрыт [показать]
     
     
  • 3.16, Аноним (16), 15:48, 05/12/2018 [^] [ответить]    [к модератору]  
  • +/
    Подскажите, как они в сравнении с hashicorp nomad?
     
     
  • 4.20, Stax (ok), 16:25, 05/12/2018 [^] [ответить]    [к модератору]  
  • +/
    > Подскажите, как они в сравнении с hashicorp nomad?

    Какой ужас ))

    Без понятия. Почитайте https://www.reddit.com/r/devops/comments/6o4ryf/nomad_vs_kubernetes/ или https://dev-ops-notes.ru/cloud/c%D1%80%D0%B0%D0%

     
     
  • 5.54, Аноним (16), 12:46, 06/12/2018 [^] [ответить]     [к модератору]  
  • +/
    Товарищи уже объяснили Nomad взяли из-за нежелания разбираться с k8s, из-за про... весь текст скрыт [показать]
     
     
  • 6.55, Аноним (16), 12:47, 06/12/2018 [^] [ответить]    [к модератору]  
  • +/
    И да, Swarm всех этих плюшек не имеет.
     
  • 3.19, username (??), 16:13, 05/12/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    Если авс то можно впихнуть ECS и вздохнуть хоть там.
     
  • 3.24, freehck (ok), 16:55, 05/12/2018 [^] [ответить]    [к модератору]  
  • +/
    Поддерживаю. Если у Вас 100+ контейнеров, то k8s маст хэв.
    Если меньше, то можно в принципе не заморачиваться. Я для малых проектов вообще поднимаю простой докер с фланелью и деплою контейнеры через ansible.
     
     
  • 4.38, Michael Shigorin (ok), 23:38, 05/12/2018 [^] [ответить]    [к модератору]  
  • +/
    100++, справляемся без дырок на дырках. :)
     
     
  • 5.51, freehck (ok), 11:08, 06/12/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    > 100++, справляемся без дырок на дырках. :)

    Чувак, то, что и без k8s можно справляться при большом количестве контейнеров -- я не спорю. Я говорю, что при таких объёмах использование k8s уже оправдано, и с ним всё-таки легче и удобнее.

     
  • 3.59, SysA (?), 18:06, 06/12/2018 [^] [ответить]    [к модератору]  
  • +/
    Вообще-то альтернатива есть - Serverless!
     
  • 2.32, SubGun (ok), 22:22, 05/12/2018 [^] [ответить]    [к модератору]  
  • +3 +/
    > Что-то про эту штуку пишут куда ни плюнь. Какие-то семинары, съезды, конференции. Баги теперь ещё.
    > Это какой-то злобный маркетинг?

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

     
  • 2.35, ГабенВульвович (?), 22:36, 05/12/2018 [^] [ответить]    [к модератору]  
  • +/
    Это такой себе клаудстэк контейнерной и микросервис-эры, который позволяет автоматизировать кластеризацию/фэйловер/конфигурацию контейнеров и служб, основанных на них.
     
  • 2.50, Dmitry77 (ok), 09:15, 06/12/2018 [^] [ответить]    [к модератору]  
  • +/
    У нас порядка 50 отдельных проектов. Можно на каждый с проект по отдельному серверу. Но обычно не требуется такие мощьностию  А в kubernates кластер можно их все запихать и не морочиться с распределением по машинам.
    Ещё есть прикольная штука- helm. это  package  manager для серверных приложение.  
     
  • 1.8, Аноним (8), 13:45, 05/12/2018 [ответить] [показать ветку] [···]     [к модератору]  
  • +3 +/
    Судя по описанию проблемы и учитывая, что проблема проявляется во всех версиях ... весь текст скрыт [показать]
     
     
  • 2.10, Аноним (10), 14:21, 05/12/2018 [^] [ответить]    [к модератору]  
  • +2 +/
    > Напомним, что код Kubernetes написан на языке Go
     
     
  • 3.11, анонзыы (?), 14:43, 05/12/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    перепишите на D))) тут почитал книжку по D и...... понял что это такая смесь си++,питон и ява( тут не оч уверен). странный замес.))) пишите на нем))
     
     
  • 4.15, Аноним (15), 15:47, 05/12/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    D - огонь! Пишу на нём. Не хватает разрабов.
     
     
  • 5.17, Аноним (17), 16:04, 05/12/2018 [^] [ответить]    [к модератору]  
  • +/
    А QMLный гуй из D использовать можно?
     
  • 4.18, Аноним (17), 16:06, 05/12/2018 [^] [ответить]    [к модератору]  
  • +/
    Наверное, имелось ввиду, что на типа безопасных языках тоже уязвимости случаются.
     
     
  • 5.41, анонзыы (?), 23:54, 05/12/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    программы пишут люди. естественно накосячить могут все. и что самое главное ни в одной программе их может и не быть, но появись они вместе создадут глюк или дыру в системе. это же известный факт. и никакой язык не может быть абсолютно безопасным. через тот же питон вызови в шелл "rm -rf /" ))) ну это утрирую , но принцип понятен. и нет абсолютно плохих языков или хороших. есть кривые руки)) и не подходящее применение( не своя стезя).
     
  • 3.36, vedronim (?), 23:23, 05/12/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    >> Напомним, что код Kubernetes написан на языке Go

    Написали бы на си, все было бы по другому.

     
     
  • 4.64, InuYasha (?), 14:11, 07/12/2018 [^] [ответить]    [к модератору]  
  • +/
    В параллельной stable-вселенной они и написаны на Си. А у нас testing-вселенная, так что, живём как живём... :(
     
  • 1.14, hellobillyboy (?), 15:43, 05/12/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    > Проблема проявляется во всех версиях Kubernetes, начиная с релиза 1.0

    т.е. больше 3х лет
    https://github.com/kubernetes/kubernetes/tags?after=v0.21.3

    очень ынтерпрайзно

     
     
  • 2.21, Аноним (21), 16:27, 05/12/2018 [^] [ответить]    [к модератору]  
  • +/
    Так не выставляй api и dash задницей на мороз и будет нормально, как будто в другом софте таких багов никогда не было
     
  • 1.22, Аноним (22), 16:31, 05/12/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +2 +/
    >уязвимость, позволяющая поднять свои привилегии

    Ну так свои же :) Расходимся.

     
     
  • 2.43, анонзыы (?), 00:20, 06/12/2018 [^] [ответить]    [к модератору]  
  • +/
    не поешь и поднять не сможешь))) брысь за редактор код писать)))
     
  • 1.23, Vitaliy Blats (?), 16:51, 05/12/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • –1 +/
    Что можно такого пихать в эти контейнеры, чего нельзя размещать под хостом, а раз уж необходимо, почему оно не может работать под нормальным KVM ?


    [сообщение отредактировано модератором]

     
     
  • 2.25, Stax (ok), 18:21, 05/12/2018 [^] [ответить]    [к модератору]  
  • +7 +/
    > Что можно такого пихать в эти контейнеры, чего нельзя размещать под хостом,
    > а раз уж необходимо, почему оно не может работать под нормальным
    > KVM ?

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

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

    И приходится дать каждому разработчику свою песочницу, которую он уже сам себе делает для каждого компонента как ему нравится - с вкривь и вкось мешаниной из распаковки тарболлов / make install, pip и npm и прочим, с условияем, что за это отвечает сам разработчик. Потому что иначе он не умеет и учиться нормально не собирается, а стороннему человеку поддерживать эту кашу невозможно.

    К счастью, можно заставить разработчика описать всю эту кашу разок в Dockerfile к каждому проекту и под угрозой увольнения заставить поддерживать хотя бы свои Dockerfile'ы к своим проектам. А дальше встает вопрос, как с этим жить. Виртуалки не вариант, потому что во-первых слишком тяжеловесные для такого применения, во-вторых нормально не скриптуются на таком уровне (не vagrant же брать, гвоздями приколоченному к virtualbox, у которого 50% функциональности отлетает при использовании libvirt плагина? И cloud-init тут тоже не спасает). Поэтому - от полного развала всего и вся спасает только docker. А дальше встают вопросы - как этот ворох контейнеров менеджить, раскидывать по машинкам с точки зрения оптимизации ресурсов, поднимать упавшие, масштабировать нужное число копий, устанавливать сетевые и прочие взаимодействия. Ну и приходим к kubernetes. Каким образом KVM-то поможет?

    А kubernetes узлы можно при желании запускать в KVM, а не на голом железе. Правда, кроме как для dev или тестирования в этом смысла не очень много.

     
     
  • 3.26, Аноним (26), 18:46, 05/12/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    спасибо за коммент. Мне многое стало понятно про хипстеров и зачем нужны контейнеры. Спасибо!
     
     
  • 4.28, Анонимус2 (?), 19:05, 05/12/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    Предлагаю описать как не используя динамическую инфраструктуру поднять новый тестовый стенд из сотни разных сервисов.
    Потом сделать то же самое, но с каким-нибудь openstack. А когда через полгода надоест пытаться это сделать - подумать что может дать докер для этого.
     
     
  • 5.29, Аноним (29), 19:46, 05/12/2018 [^] [ответить]     [к модератору]  
  • +/
    Спасибо, что подыграли Выше так и написали, что те, кто сами решать возникающие... весь текст скрыт [показать]
     
     
  • 6.34, Stax (ok), 22:33, 05/12/2018 [^] [ответить]    [к модератору]  
  • +2 +/
    > Спасибо, что подыграли. Выше так и написали, что те, кто сами решать возникающие проблемы не хотят, просто переваливают всё на докер.

    Ну так дело, в целом, не в решении проблем и не в переваливании на докер.

    Докер просто замечательный инструмент, чтобы делегировать ответственность за окружение приложения от админа к разработчику. Потому что даже если все не настолько ужасно, как я написал в примере выше, проблема того, что разработчик хочет чего-то, а у админа нет времени / желания разбираться / объяснять, что так глобально нельзя, а можно максимум в небольшой песочнице - возникает. И докер это хороший способ убрать эту проблему. Убрали - и больше разработчику не нужно чуть что, ходить на поклон к админу и согласовывать окружение. Это офигенно ускоряет процесс от разработки до выкатывания. Опять же, это возможность иметь CI, где разработчик может без каких-либо проблем менять продакшен окружение (правкой Dockerfile) в любой момент, когда это требуется.
    Ну а использование докера в продакшене очень быстро приводит к внедрению k8s. Ибо если не он, то что?

     
     
  • 7.39, Michael Shigorin (ok), 23:43, 05/12/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    > ...а у админа нет времени / желания разбираться / объяснять, что так
    > глобально нельзя, а можно максимум в небольшой песочнице - возникает.

    Голые cgroups -- это _не_ песочница; так, авоська для удобствия.

    > И докер это хороший способ убрать эту проблему. Убрали - и больше
    > разработчику не нужно чуть что ходить на поклон к админу
    > и согласовывать окружение.

    ...и не только разработчику ;-]

     
  • 7.49, лютый лютик_ (?), 09:10, 06/12/2018 [^] [ответить]    [к модератору]  
  • +/
    >чтобы делегировать ответственность за окружение приложения от админа к разработчику

    А не сильно жирно разрабам решать на чём прод будет крутиться?

    Если в конторе прод на CentOS/RHEL, то тестовое окружение должно быть на Центосе. На десктопе пусть себе абанту ставит. И зачем в данной схеме докер?

    Вообще, проблема совместимости сильно раздута, для сишников это может и актуально, а всяким жаберам, питонщикам да JSникам плюс минус пара версий ни роялит.

     
     
  • 8.56, Аноним (16), 13:33, 06/12/2018 [^] [ответить]     [к модератору]  
  • +/
    Вот простой пример из реальной жизни у разработчиков Федора, на продакшене Cent... весь текст скрыт [показать]
     
     
  • 9.57, Аноним (16), 13:37, 06/12/2018 [^] [ответить]    [к модератору]  
  • +/
    > Во время сбокри имиджа волюм не используется

    Имеется в виду "во время сборки для CI или продакшена", т.е. не во время разработки.

     
  • 9.63, лютый лютик_ (?), 08:23, 07/12/2018 [^] [ответить]    [к модератору]  
  • +/
    >у разработчиков Федора,на продакшене CentOS.
    >Баги у первых не воспроизводятся, но присутствуют
    >на центосе из-за разных версий зависимостей

    Я так и не понял. В каких-то центосовых либах якобы  баги, а в федоре нет (что уже звучит фантастично). Девки ваши соберут свою прожку с либами от федоры и выкатят в прод? Ну в пень, это не решение проблемы.

    А если докер им нужен только для "более удобного дебага с центосовыми либами, сидя в федоре", то спрашивается, а зачем потом тащить этот ваш доцкер дальше машины девы?

    То что доцкер решает какие-то проблемы никто не спорит, плохо то, что он привносит другие проблемы плюс оверхед _в разработку_. У меня есть на виду один фанатик. Иногда на банальных вещах стопорится на день. Чего-то там пересобирает, ковыряет, перенастраивает.

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

     
  • 7.52, Crazy Alex (ok), 12:44, 06/12/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    Я бы по-другому сказал - докер - это способ разделить софт на компоненты с явно указанными зависимостями.  Нужен какой-то порт открытый - пропиши, нужен доступ куда-то на диск - пропиши, и так далее. В общем, естественное следствие массового увеличения сложности софта и способ борьбы с ней.

    То есть не "у кого-то нет желания разбираться", а совершенно закономерное повышение уровня, которое началось с того, что нумерованным ячейкам памяти стали присваивать имена, а инструкции писать символьными обозначениями.

     
  • 7.58, Аноним (58), 17:22, 06/12/2018 [^] [ответить]     [к модератору]  
  • +/
    Соглашусь Докер, конечно классный инструмент, но заставляет очень быстро деград... весь текст скрыт [показать]
     
  • 6.60, SysA (?), 18:20, 06/12/2018 [^] [ответить]    [к модератору]  
  • +/
    Вообще-то в Докер-контейнере нет ОС! Потому-то они и такие маленькие... и это их основное преимущество перед КВМ и пр.
     
  • 3.31, КГБ СССР (?), 22:15, 05/12/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    Переводя на общепонятный русский, необходимость в контейнерной изоляции вызвана к жизни единственно низким уровнем квалификации молодой поросли эм… клавиатурных работников?
     
     
  • 4.33, Аноним (33), 22:28, 05/12/2018 [^] [ответить]    [к модератору]  
  • +/
    Истинно так.
     
  • 4.37, vedronim (?), 23:29, 05/12/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    > Переводя на общепонятный русский, необходимость в контейнерной изоляции вызвана к жизни
    > единственно низким уровнем квалификации молодой поросли эм… клавиатурных работников?

    Нет. Причина в фрагментации линукса. Васяны, делающие свои дистры почему то надеются, что под них тут же начнут все подстраиваться.

     
     
  • 5.40, Michael Shigorin (ok), 23:45, 05/12/2018 [^] [ответить]     [к модератору]  
  • –3 +/
    Есть формальная логика, есть женская -- но вот по продемонстрированной выше вас... весь текст скрыт [показать]
     
  • 4.42, Борщдрайвен бигдата (?), 23:55, 05/12/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    Нет. Вернее, не только.
    Ещё точнее: если бы k8s возник _только_ по вышеуказаной причине, то его бы никто не продал, будь этим кем-то сам гугл.
     
  • 4.46, cutlass (?), 05:58, 06/12/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    На разработчиков проще всего свалить все проблемы. Это слишком близоруко.
     
     
  • 5.47, КГБ СССР (?), 08:11, 06/12/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    > На разработчиков проще всего свалить все проблемы. Это слишком близоруко.

    Прости, если сможешь, Леннарт. Я был политически и морально близорук.

     
     
  • 6.48, cutlass (?), 08:47, 06/12/2018 [^] [ответить]    [к модератору]  
  • +/
    Молодец! Осталось поработать над ошибками.
     
  • 4.53, Crazy Alex (ok), 12:46, 06/12/2018 [^] [ответить]    [к модератору]  
  • +/
    Нет. Причина, как и всегда - в усложнении массово применяемого софта (включая условия его использования) и необходимости сохранять при этом хоть как-то разумные бюджеты на его написание и поддержку.
     
     
  • 5.61, SysA (?), 18:23, 06/12/2018 [^] [ответить]    [к модератору]  
  • +/
    Не только и не столько...
    Суть в модульности и масштабируемости. И, как побочный эффект, - упрощение системы.
     
  • 3.44, Онаним (?), 00:49, 06/12/2018 [^] [ответить]    [к модератору]  
  • +/
    > В какой-то момент приходится признать

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

     
  • 3.45, Аноним (45), 01:36, 06/12/2018 [^] [ответить]     [к модератору]  
  • +1 +/
    Здравствуйте, я тот самый дяденька, который заставляет их приводить код в состоя... весь текст скрыт [показать]
     
  • 1.27, Аноним (27), 18:52, 05/12/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    https://gitlab.freedesktop.org/polkit/polkit/issues/74

    PolicyKit: Users with UID greater than INT_MAX can execute any systemctl command

     
  • 1.30, Онаним (?), 20:47, 05/12/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +3 +/
    Девопсненько.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:


      Закладки на сайте
      Проследить за страницей
    Created 1996-2018 by Maxim Chirkov  
    ДобавитьПоддержатьВебмастеруГИД  
    Hosting by Ihor