Summary: | Добавить опцию запрета создания жестких ссылок. | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | nbr <nbr> |
Component: | chrooted | Assignee: | placeholder <placeholder> |
Status: | NEW --- | QA Contact: | qa-sisyphus |
Severity: | enhancement | ||
Priority: | P5 | CC: | aen, george, glebfm, imz, ldv, placeholder |
Version: | unstable | ||
Hardware: | x86_64 | ||
OS: | Linux |
Description
nbr
2020-10-16 21:08:06 MSK
(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 Да, конечно, это должен быть конфигурационный файл. |