SetCap устарел?
Вы используете его после команды dd . Поскольку вы скопировали таблицу разделов, вам нужно сначала сообщить ядру об изменении, например, запустив partprobe / dev / sdb .
По сути, происходит то, что в метаданных файловой системы хранится уникальное значение (UUID). Когда вы копируете целые разделы (как вы делаете с dd ), вы получаете два раздела (и, следовательно, две файловые системы) с одним и тем же UUID. Столько всего уникальности! Это проблема, если, например, вы пытаетесь использовать UUID для монтирования файловой системы.
Чтобы решить эту проблему, вы изменяете UUID на копии - это делает строка tune2fs . Вам необходимо запустить его на каждом разделе целевого диска, который содержит файловую систему ext2 / 3/4. Для других типов файловых систем вам потребуются другие утилиты.
Правильно будет сказать, что обычно systemd не будет работать с файловыми возможностями, управляемыми с помощью setcap, и вместо этого потребует от вас настроить их как часть сервисного модуля.
Так что это не значит, что setcapполностью устарел... (Возможно, для него есть допустимое использование за пределами служб, запускаемых systemd. )Но, по крайней мере, это не работает для системных служб.
На самом деле файловые возможности (, установленные setcap), всегда были сомнительными и сомнительными, с самого начала... Они требуют использования "наследуемых" возможностей, которые были несколько плохо продуманы и имели много недостатков... Функция ядра «окружающих» возможностей была введена для решения многих из этих проблем, и это то, что новые системы принимают (systemd, включенный сюда, как вы можете видеть, вы устанавливаете AmbientCapabilities=для вашего сервиса, чтобы он мог управлять для привязки к младшим портам.)
Тема возможностей довольно сложна... Возможно, для более мягкого ознакомления с этой проблемой вы можете проверить "Наследование возможностей" на LWN. Для получения полной информации (, включая некоторые алгебраические обозначения наборов возможностей ), обратитесь к справочной странице возможностей (7 ).