Chrooted в строке 137 в Copy пытается всегда сделать ln для копируемого файла, затем пытается его скопировать. Предлагаю ввести ключ для update_сhrooted (например -s) который бы позволял сразу делать cp, не пытаясь сделать ln. Такое полезно в системах с selinux, где этот hardlinked файл технически будет иметь только одну метку а по смыслу нахождения в основном месте и в chroot он должен был бы иметь разные метки. В случае копирования создаются два файла с разными метками а в случае hardlink - один файл с "не той" меткой в каком-нибудь месте.
(In reply to nbr from comment #0) > Chrooted в строке 137 в Copy пытается всегда сделать ln для копируемого > файла, затем пытается его скопировать. > Предлагаю ввести ключ для update_сhrooted (например -s) который бы > позволял сразу делать cp, не пытаясь сделать ln. Добавлять утилите update_сhrooted параметр, меняющий её поведение, бессмысленно, поскольку невозможно пропатчить всех пользователей этой утилиты. Нужен какой-то другой вариант, не затрагивающий этих пользователей.
(In reply to Dmitry V. Levin from comment #1) > (In reply to nbr from comment #0) > > Chrooted в строке 137 в Copy пытается всегда сделать ln для копируемого > > файла, затем пытается его скопировать. > > Предлагаю ввести ключ для update_сhrooted (например -s) который бы > > позволял сразу делать cp, не пытаясь сделать ln. > > Добавлять утилите update_сhrooted параметр, меняющий её поведение, > бессмысленно, поскольку невозможно пропатчить всех пользователей этой Странный ответ. Не бессмысленно, я же указал осмысленный вариант использования этого параметра. > утилиты. > Нужен какой-то другой вариант, не затрагивающий этих пользователей. Каким образом добавление нового ключа утилиты, о котором не знают и не собираются знать текущие ее пользователи
Я предлагаю сделать этот ключ не для общего употребления, а только для создания специальных дистрибутивов с Selinux. Поведение сhrooted для обычных дистрибутивов менять не придется, равно как и патчить зависящие от них программы.
(In reply to nbr from comment #2) > (In reply to Dmitry V. Levin from comment #1) > > (In reply to nbr from comment #0) > > > Chrooted в строке 137 в Copy пытается всегда сделать ln для копируемого > > > файла, затем пытается его скопировать. > > > Предлагаю ввести ключ для update_сhrooted (например -s) который бы > > > позволял сразу делать cp, не пытаясь сделать ln. > > > > Добавлять утилите update_сhrooted параметр, меняющий её поведение, > > бессмысленно, поскольку невозможно пропатчить всех пользователей этой > Странный ответ. Не бессмысленно, я же указал осмысленный вариант > использования этого параметра. К сожалению, нет. > > утилиты. > > Нужен какой-то другой вариант, не затрагивающий этих пользователей. > Каким образом добавление нового ключа утилиты, о котором не знают и не > собираются > знать текущие ее пользователи Нет смысла добавлять ключ, который по смыслу следует обязательно использовать во всех скриптах, вызывающих update_сhrooted, при некотрых определённых условиях, например, в системах с selinux.
(In reply to nbr from comment #3) > Я предлагаю сделать этот ключ не для общего употребления, а только для > создания специальных дистрибутивов с Selinux. Поведение сhrooted для обычных > дистрибутивов менять не придется, равно как и патчить зависящие от них > программы. Поскольку update_сhrooted запускают различные скрипты в пакетах, если добавить параметр к update_сhrooted и при этом не пропатчить ВСЕ эти скрипты, то желаемый эффект не будет достигнут.
(Ответ для Dmitry V. Levin на комментарий #4) > (In reply to nbr from comment #2) > > (In reply to Dmitry V. Levin from comment #1) > > > (In reply to nbr from comment #0) > > > > Chrooted в строке 137 в Copy пытается всегда сделать ln для копируемого > > > > файла, затем пытается его скопировать. > > > > Предлагаю ввести ключ для update_сhrooted (например -s) который бы > > > > позволял сразу делать cp, не пытаясь сделать ln. > > > > > > Добавлять утилите update_сhrooted параметр, меняющий её поведение, > > > бессмысленно, поскольку невозможно пропатчить всех пользователей этой > > Странный ответ. Не бессмысленно, я же указал осмысленный вариант > > использования этого параметра. > > К сожалению, нет. > > > > утилиты. > > > Нужен какой-то другой вариант, не затрагивающий этих пользователей. > > Каким образом добавление нового ключа утилиты, о котором не знают и не > > собираются > > знать текущие ее пользователи > > Нет смысла добавлять ключ, который по смыслу следует обязательно > использовать во всех скриптах, вызывающих update_сhrooted, при некотрых > определённых условиях, например, в системах с selinux. Может быть, включить определение выполнения этих условий?
(In reply to AEN from comment #6) > (Ответ для Dmitry V. Levin на комментарий #4) > > Нет смысла добавлять ключ, который по смыслу следует обязательно > > использовать во всех скриптах, вызывающих update_сhrooted, при некотрых > > определённых условиях, например, в системах с selinux. > > Может быть, включить определение выполнения этих условий? Я объяснил, почему не надо добавлять ключ и вообще менять command line interface под эту задачу. Надо просто придумать какой-то другой способ настройки поведения update_сhrooted.
Кротко скажу, что такая опция может быть полезна и для систем или дистрибутивов общего назначения, в которых администраторы хотят одинакового поведения сhrooted (всегда копирование) для систем с разной разметкой файловых систем.
А если такой вариант? SourceIfNotEmpty /etc/sysconfig/chrooted if [ "$CHROOTED_NO_HARDLINKS" == 1 ] ; then fi
Да, конечно, это должен быть конфигурационный файл.
