LINUX.ORG.RU

systemd 218

 ,


3

5

12 декабря был представлен очередной релиз системного менеджера systemd, совмещающего в себе функции системы инициализации, ведения журнала и управления сессиями пользователей. systemd основан на модели зависимостей (в противовес событийной модели), производит отслеживание процессов запущенных сервисов при помощи механизма cgroups ядра Linux, поддерживает механизмы сокет- и dbus-активации сервисов и предоставляет удобный декларативный синтаксис для описания демонов и других сущностей. Это позволяет производить агрессивную параллелизацию при запуске и остановке сервисов.

В рамках проекта также разрабатывается ряд легковесных приложений и демонов, выполняющих второстепенные, но распространённые задачи по управлению системой — от настройки подсистемы VT (systemd-vconsole-setup) до управления сетью (systemd-networkd) и профилирования загрузки (systemd-bootchart).

Список изменений:

  • Все компоненты systemd, обладающие конфигурационными файлами в /etc/systemd, теперь умеют считывать настройки из соответствующих *.d-директорий в /usr/lib, /run и /etc.

    Например, /etc/systemd/system.conf можно дополнять из /{usr/lib,run,etc}/systemd/system.conf.d/*.conf.

  • Добавлена команда systemctl edit, которая позволяет редактировать unit-файлы (используется редактор, указанный в переменной окружения $EDITOR).

    Возможные режимы работы таковы:

    • (по умолчанию): «режим дополнения», т. е. редактирование нового drop-in'а (создаётся и открывается /etc/systemd/system/$unit.d/override.conf)
    • --full: «режим исправления», т. е. редактирование всего юнит-файла (он предварительно копируется в /etc/systemd/system, если необходимо)
    • --runtime: «режим временных изменений», т. е. вместо /etc используется /run и все внесённые изменения живут только до перезагрузки
  • Команда systemctl is-enabled теперь выводит «indirect» вместо «static» (при этом код возврата равен 0) в тех случаях, когда секция [Install] юнита содержит только директивы Also=, т. е. когда сам юнит не может быть включен, но «включает» другие юниты.
  • Команда systemctl status ЮНИТ теперь выводит также и «предлагаемое» состояние юнита согласно preset'ам. Это показывает, должен ли юнит быть включен согласно дистроспецифичному дефолту.

    Пример:

    $ grep -R remote-fs.target /usr/lib/systemd/system-preset
    /usr/lib/systemd/system-preset/90-systemd.preset:enable remote-fs.target
    
    $ systemctl status remote-fs.target
    ● remote-fs.target - Remote File Systems
       Loaded: loaded (/usr/lib/systemd/system/remote-fs.target; disabled; vendor preset: enabled)
    

  • Команда systemd-run теперь поддерживает отложенный запуск команд в стиле at(1) (параметры командной строки --on-calendar и аналогичные). Это реализовано с помощью создания временного timer-юнита наряду с основным service-юнитом (поддержка создания timer-юнитов как раз была добавлена в API systemd).
  • В команде busctl, предназначенной для работы с шиной D-Bus, добавлены следующие подкоманды и параметры командной строки:
    • busctl capture (захват всех данных, проходящих через шину, в формате libpcap)
    • busctl tree (отображение дерева объектов для конкретного сервиса или для всех сервисов на шине)
    • busctl introspect (отображение подробной информации о конкретном объекте на шине)
    • busctl call, busctl get-property и busctl set-property (предназначение очевидно из названий)
    • busctl --augment-creds= (включение или отключение сбора вспомогательных данных о процессах на шине из /proc)

      Последняя опция по умолчанию включена, но в некоторых случаях это может привести к race conditions, поэтому и была добавлена возможность её отключения.

  • В команде journalctl добавлены параметры командной строки --vacuum-size= и --vacuum-time=, позволяющие принудительно удалить старые файлы журнала. Как легко понять из названий параметров, критерием очистки может быть или суммарный размер файлов журнала, или давность сообщений в конкретном файле.
  • В команде systemd-nspawn добавлены параметры командной строки --link-journal=try-guest и --link-journal=try-host, которые работают аналогично значениям guest и host (а именно — включают объединение журналов хоста и контейнера), но не возвращают ошибку, если на хосте ведение постоянного журнала отключено.

    Параметр командной строки -j теперь является синонимом для --link-journal=try-guest.

  • Команда systemd-inhibit при отображении списка активных ингибиторов теперь поддерживает фильтрацию по типу (block или delay).
  • Для каждой директивы вида ConditionXYZ= в секции [Unit] unit-файлов добавлена аналогичная директива AssertXYZ= в той же секции.

    Отличие между ними состоит в том, что невыполнение Condition-директив приводит к пропуску (игнорированию) юнита, а невыполнение Assert-директив переводит юнит в состояние «failed».

  • В секциях [Scope] и [Service] unit-файлов добавлена директива Delegate=, разрешающая процессам юнита самостоятельно управлять своим поддеревом контрольных групп.
  • В секции [Service] unit-файлов добавлена директива SmackProcessLabel=, позволяющая установить для всех процессов юнита указанную метку SMACK64.
  • Директива ConditionSecurity= unit-файлов теперь может принимать значение audit, что будет приводить к проверке доступности audit-подсистемы ядра.
  • systemd-coredump теперь собирает и кладёт в журнал вместе с core-дампом некоторое количество метаданных об упавшем процессе, а именно:
    • контрольные группы, к которым принадлежал процесс (/proc/$PID/cgroup)
    • список переменных окружения и их значения (/proc/$PID/environ)
    • карту адресного пространства процесса (/proc/$PID/maps)
    • рабочую директорию (/proc/$PID/cwd)
    • корневую директорию (/proc/$PID/root)
    • состояние процесса (/proc/$PID/status)
    • список открытых файловых дескрипторов (/proc/$PID/fd)
  • journald теперь умеет собирать сообщения audit-подсистемы ядра (с обработкой сопутствующих метаданных) и записывать их в общий лог. В частности, это означает, что journalctl становится альтернативой традиционному audit-клиенту ausearch.
  • systemd-networkd теперь поддерживает:
    • конфигурирование VXLAN-устройств (секция [VXLAN] netdev-файлов)
    • указание «стоимости» портов bridge-устройств (директива Cost= в секции [Bridge] network-файлов)
    • настройку правил IP source routing (директива Source= в секции [Route] network-файлов)
    • выбор сетевого интерфейса по его исходному имени (до переименования; директива OriginalName= в секции [Match] link-файлов)
    • изменение MAC-адреса и MTU интерфейса из network-файлов (директивы MACAddress= и MTUBytes= в секции [Link] network-файлов)
  • В systemd-networkd начата работа по реализации протокола PPPoE.
  • NSS-модуль nss-myhostname теперь ресолвит имя «gateway» в IP-адрес шлюза по умолчанию. Если таковых несколько — они сортируются по значению метрики.

    Отмечу, что это изменение не нарушает работу конфигураций, в которых имя «gateway» уже как-либо используется, поскольку модуль nss-myhostname обычно идёт последним в списке NSS-модулей.

  • macvlan-устройства, создаваемые systemd-nspawn внутри контейнеров, теперь имеют стабильные MAC-адреса (в том смысле, что они не будут изменяться каждый раз).
  • systemd-cryptsetup-generator теперь поддерживает указание key-файлов и назначение имён для отдельных устройств из командной строки ядра (luks.key=<UUID>=<имя файла> и luks.name=<UUID>=<назначаемое имя устройства>).
  • В systemd-tmpfiles добавлено действие t — назначение файлу произвольных расширенных атрибутов (xattrs).
  • systemd-localed теперь опционально зависит от libxkbcommon. Эта библиотека будет использоваться для проверки корректности устанавливаемых настроек раскладки клавиатуры X11 (напр., с помощью localectl set-x11-keymap).
  • В systemd-hostnamed список текстовых описаний типов системы (chassis type) был пополнен значением «embedded».
  • systemd-rfkill теперь ассоциирует запоминаемое состояние rfkill'а не с его именем (rfkill0, rfkill1, ...), а с комбинацией его типа (wlan, bluetooth, ...) и свойства ID_PATH.

    Это связано с тем, что имя rfkill'а не обязано сохраняться между перезагрузками или переподключениями устройства. Более того, в последнем случае оно никогда не остаётся прежним.

  • База данных аппаратного обеспечения (hwdb) udev'а теперь содержит базу данных разрешений оптических сенсоров мышей. Она будет использоваться в libinput для автоматической коррекции ускорения курсора.

    Ситуация более подробно описана в этом сообщении.

  • systemd теперь умеет корректно обрабатывать ситуации, в которых система одновременно
    • не имеет файла /etc/machine-id
    • запускается с корневой ФС в режиме «только чтение»

    Для обработки этих случаев была добавлена вспомогательная утилита systemd-machine-id-commit, которая запускается сразу после перемонтирования корневой ФС в режим «чтение и запись» и атомарно перемещает временный файл machine-id из tmpfs в /etc/machine-id.

>>> Объявление о релизе

★★★★★

Проверено: maxcom ()
Последнее исправление: maxcom (всего исправлений: 7)
Ответ на: комментарий от A-234

очистка пароля происходит в самом конце работы

И что? Пока память не освобождена — она в любом случае не попадёт другому процессу в адресное пространство.

после кучи лишней грядки free, что уже само по себе глупо

Зато консистентно и исключает «сюрпризы» в том случае, когда кто-либо решит внести этот код в состав другой программы.

Получается goto мы используем только в путь, хотя можно было одним оператором if обойтись

(предпосылки неверны)

Буфер с паролем должен очищаться внутри process_root_password а не отдаваться на откуп main'у

Какая разница, где он очищается?

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

Это аргументы программы (что следует из их названий). «Срёт» в них только parse_argv().

В общем стиль ужасен.

Не согласен.

Отлаживать такой код непросто.

Это всего лишь слова. Что конкретно в этом коде сложно отлаживать?

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

ditto

intelfx ★★★★★
() автор топика
Ответ на: комментарий от AS

Всё сказанное не имеет отношения к исходному утверждению, которое ты оспариваешь:

«новые сущности» добавляются отдельными компонентами, гибкость и надёжность проекта в целом от этого не уменьшается

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от anonymous

клоунов со времён болгеноса

А ведь насчет HTML Денис был абсолютно прав.

LongLiveUbuntu ★★★★★
()
Ответ на: комментарий от vurdalak

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

intelfx ★★★★★
() автор топика
Ответ на: комментарий от intelfx

Всё сказанное не имеет отношения к исходному утверждению, которое ты оспариваешь:

Наоборот, имеет напрямую. Так как замена второстепенного приложения ведёт к замене основного и ставит под ненужную угрозу последующий перезапуск системы.

AS ★★★★★
()
Ответ на: комментарий от intelfx

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

vurdalak ★★★★★
()
Ответ на: комментарий от AS

Я говорю, что добавление компонентов в systemd (как проект) не уменьшает гибкости и надёжности уже существующего там кода.

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

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

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от vurdalak

rsyslog и произвольный бэкенд по выбору.

Система хранения логов journald — не замена всему, что есть, и никогда таковой не позиционировалась.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от intelfx

Ну вот я так и написал, что возможно мне надоест и я перелезу на rsyslog. Но пока хотелось бы иметь поменьше костылей и stick to journald.

Посмотрим, когда прилетит 218 в репозитории.

vurdalak ★★★★★
()
Ответ на: комментарий от intelfx

Я говорю
Ты говоришь

Так рассматривать надо в комплексе, важен-то конечный результат.

если мы рассматриваем компонент, ранее существовавший
в виде отдельного проекта.

Я даже конкретно назвал компонент - udev. А ещё есть logind, который одеяло на себя тянет. Следовало изначально разбить минимум на два проекта: собственно init, и всё остальное.

AS ★★★★★
()
Ответ на: комментарий от vurdalak

что возможно мне надоест и я перелезу на rsyslog

Кстати, в syslog-ng 3.6 добавили journal в источники логов...

AS ★★★★★
()
Ответ на: комментарий от vurdalak

Вообще я не очень понимаю, почему там не БД, в которой можно сделать нормальную быструю выборку.

Собственно, я отвечал на этот вопрос :) Именно поэтому там не полноценная реляционная БД. А оптимизировать реализацию — ну, надеюсь, Michal Schmidt доделает то, что хотел.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от AS

Толку-то с разбития, если они нужны друг другу по смыслу? udev, кстати, на данный момент работает без systemd (или я не прав?), и если они лежат в одном пакете — это исключительно проблемы дистрибутива.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от intelfx

Какая разница, где он очищается?

Это неожиданно когда приходится делать действие явно не предусмотренное при вызове функции. Вы все равно больше этот буфер не трогаете, почему не почистить его там где он используется, зачем его делать общедоступным?
Сами себе противоречите: «исключает «сюрпризы»». Сюрпризов там как раз полно. Этот код вообще лучше никуда не вносить а переписать с нуля. Чем в BSD и занялись.

предпосылки неверны

Какие предпосылки? Вы можете внятно объяснить что имели в виду? То что одним if обойтись нельзя? Или то что free тут нужен?

Что конкретно в этом коде сложно отлаживать?

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

«Срёт» в них только parse_argv().

Да щаз. А как быть с prompt_root_password(), например?

A-234 ★★★★★
()
Ответ на: комментарий от intelfx

Толку-то с разбития, если они нужны друг другу по смыслу ?

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

udev, кстати, на данный момент работает без systemd (или я не прав?)

Прав.

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

А вот тут - неправ. А говоришь, что с пакетными менеджерами знаком, и вообще с разработкой. Ты предлагаешь держать в дистрибутиве две версии тарбола, одну для сборки init, а другую - для сборки всего остального с библиотеками от первой, условно стабильной ? В теории оно возможно наверное, но зачем было тогда всё в один проект тащить-то ? :-)

В чём и проблема.

AS ★★★★★
()
Ответ на: комментарий от intelfx

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

vurdalak ★★★★★
()
Ответ на: комментарий от alex-w

Потому что ты ограничил число systemd багов 1000-й.

Действительно, ограничил.

Теперь, когда ссылка привлекла пристальное внимание общественности, замечу, что в результаты быстрого поиска попали все баги, в описании которых почему-либо упоминается systemd, в том числе и не имеющие к нему отношения (например, 1, 2, 3, 4, 5 и т. д.). Если же поискать только незакрытые баги в systemd как таковом, найдется 335 штук, не больше и не меньше.

dexpl ★★★★★
()
Ответ на: комментарий от A-234

Вы все равно больше этот буфер не трогаете, почему не почистить его там где он используется

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

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

Это всего лишь слова.

Какие предпосылки? Вы можете внятно объяснить что имели в виду?

Да, я имел в виду, что free() нужен.

Вроде написал по-русски: куча статиков

Их конечное количество, по смыслу они как раз глобальны. И ещё имеет значение тот факт, что программа небольшая — в таких масштабах пять-семь глобальных почти_констант выглядят лучше, чем гирлянды из &arg1, &arg2, &argN.

Да щаз. А как быть с prompt_root_password(), например?

Хех, пропустил. (Хотя я бы поспорил следующим образом — здесь перезапись допустима, т. к. имеет место оверрайд параметра).

intelfx ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Хорошо, что journald как и systemd становится стандартом de facto.

У syslog-ng источников достаточно. Одним больше, одним меньше - не существенно.

AS ★★★★★
()
Ответ на: комментарий от AS

Не надо, чтобы друг другу. Надо, чтобы у udev был некоторый стандартизированный интерфейс, которым бы init пользовался.

Check (libudev).

Вот udev на init мог бы и быть завязан через библиотеки от init

Check (org.freedestop.systemd1.Manager). Насколько мне известно, там приватных интерфейсов нет.

Ты предлагаешь держать в дистрибутиве две версии тарбола, одну для сборки init, а другую - для сборки всего остального с библиотеками от первой, условно стабильной ?

Не распарсил.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от intelfx

Не распарсил.

Ты вот написал:

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

Ты тут что имел ввиду ? Что init в одном подпакете, udev в другом, так ? Естественно, в нормальных дистрибутивах так и будет. Но. Так как и init, и udev собирались в рамках одного пакета, то у них образуются зависимости между собой, к примеру, через какую-нибудь библиотеку. libsystemd-daemon, скажем. Таким образом, хотя udev и в отдельном подпакете, его обновление потащит за собой, через libsystemd-daemon, и обновление самого systemd.

Кроме того, обновление пакета с исходниками вызовет в репозитарии замену init и так: ввиду увеличения версии, init просто попытается обновиться при каком-нибудь apt-get update.

Соответственно выход тут - из пакета одной, вылизанной, версии собирать systemd и libsystemd-daemon (и что там ещё надо для самого init), а из другого, более-менее обновляемого, собирать всё остальное, с использованием библиотек первого пакета. И это - лишняя головная боль.

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 2)

Слышал кто-нибудь про SMF из солярки? Оно живое? Его возможно прикрутить к линуксу?

Meyer ★★★★★
()
Ответ на: комментарий от Meyer

Оно живое?

В солярке - да.

Его возможно прикрутить к линуксу?

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

ioway
()
Ответ на: комментарий от Meyer

А очень кошерная штука. Ребята, которые SMF писали, знали свое дело.

Знаю, пользовал. Вот только их целевое назначение кластерные решения со сложными сценариями старта и централизованное управление. Зачем тащить это на десктоп?

ioway
()
Ответ на: комментарий от Meyer

А зачем тащить туда systemd?

Вон там выше у волосатика спроси. Я хз, к чему эти наркоманы стремятся.

ioway
()
Ответ на: комментарий от intelfx

И указать на это не является «фанбойством».

Это всего лишь мнение фанбоя.

andreyu ★★★★★
()

Снова писклявый шаповалов раскудахтался...

anonymous
()
Ответ на: комментарий от vurdalak

настрою, чтобы журналы бились на более мелкие куски

Я бы вообще настроил, чтоб журнал только последние 2 загрузки содержал - если десктоп нестабилен, а если стабилен, то вообще на диск ничего не писал. На сервере же один чёрт экспорт в какую-нить ELSA поднимать.

anonymous
()
Ответ на: комментарий от Meyer

Его возможно прикрутить к линуксу?

Дерзай, чё. Безумству храбрых поём мы песню, безумство храбрых сродни психозу :)

anonymous
()
Ответ на: комментарий от anonymous

Мне иногда нужны логи всяких демонов. Но ставить что-то сторонние не хочется.

vurdalak ★★★★★
()

...спасибо за новость. Очень толково преподнесена.

...от обсуждения воздержусь, т.к. пока что на Debian_Stable. Понял из всего срача, что вещь годная и интересная.

Google_Play
()
Ответ на: комментарий от anonymous

При таком подходе существует ненулевая вероятность нарваться на «нестабильный» с пустым логом.

Myau ★★★★
()
Ответ на: комментарий от Google_Play

Понял из всего срача, что вещь годная и интересная.

А ты отлично фильтруешь неадекватов - завидую.

anonymous
()
Ответ на: комментарий от anonymous

пиво в школьном возрасте пить вредно!

anonymous
()
Ответ на: комментарий от anonymous

видимо неадекват неадеквата видит издалека :)

anonymous
()
Ответ на: комментарий от Myau

существует ненулевая вероятность нарваться на «нестабильный» с пустым логом.

Ну включил логи и вперёд - делов-то. Десктоп же - он как правило не для медитации на логи :)

anonymous
()
Ответ на: комментарий от anonymous

т.е. для десктопа много, для сервера мало... и в чем профит?

anonymous
()
Ответ на: комментарий от anonymous

А ты отлично фильтруешь неадекватов - завидую.

...[tag]LOR-school[/tag]

Google_Play
()
Ответ на: комментарий от A-234

Это неожиданно когда приходится делать действие явно не предусмотренное при вызове функции.

r = parse_argv(argc, argv);
{ "root-password",        required_argument, NULL, ARG_ROOT_PASSWORD        },
"     --root-password=PASSWORD  Set root password\n"

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

Может быть появится фича, по которой по тому же рутовому паролю понадобится монтировать шифрованный диск. В твоём случае - не расширяемый говнокод, в Лёнином - расширяемый код.

А без goto, пришлось бы 4 раза занулять пароль до вызова process_root_password(), даже если забить на освобождение остального.

PS: В твоём случае как раз есть уязвимость, т.к. если пароль был введён как параметр, и был вызван косяк до process_root_password(), то, в твоём случае, пароль не будет очищен, т.к. его очистка отдана на откуп process_root_password(). Если же пароль зачищать не только в process_root_password(), то это как раз Лёнин вариант.

Короче, хреновый из тебя безопасник.

Ivan_qrt ★★★★★
()
Ответ на: комментарий от Ivan_qrt

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

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

Может быть появится фича, по которой по тому же рутовому паролю понадобится монтировать шифрованный диск. В твоём случае - не расширяемый говнокод, в Лёнином - расширяемый код.

Значит пусть спросит еще раз пароль! Ты еще скажи на стенке записать пароль, что бы все видели.

А без goto, пришлось бы 4 раза занулять пароль до вызова process_root_password(), даже если забить на освобождение остального.

Он и не должен там зануляться. Само по себе хранение пароля преступление. Ты когда подходишь к банкомату, он же не спрашивает один раз пароль на все операции. А просит каждый раз ввести его. А теперь представь, что функцию main убрали, а функцию используют в другом месте. Что будет тогда? Правильно, пароль остается в памяти, а значит и потенциальная угроза. Выделил память в функции, значит освободи, если это не API интерфейс.

vitalikp
()
Ответ на: комментарий от intelfx

Очистка логически «связана» с освобождением памяти.

Ниразу, иначе либо вызываете free либо делаете метод совмещающий clear_string(arg_root_password) и free. Получается вроде деструктора на чистом C, но так много где делают.

Это всего лишь слова.

О да, приведу еще раз:
куча статиков, очистка пароля происходит в самом конце работы. И это только по пипеточному коду. Частность, которая объясняет почему Торвальдса от такого разраба тошнит.

Их конечное количество

А где их бесконечное количество? Демагогией не занимайтесь.

Да, я имел в виду, что free() нужен.

Зачем? Он прямо пред выходом из main. Очистите вы память или нет ядро все равно ее заберет, времена ДОСа давно прошли. А вот если программа загнется на каком нибудь free до clear_string(arg_root_password) то пароль утек, но для вас это покраска велосипеда.

по смыслу они как раз глобальны.

Этот смысл доступен только вам.

A-234 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.