Пакет нарушает ALT Secure Packaging Policy, на что ежедневно в почту жалуется logrotate (3.9.1-alt2 и выше): =8<======================================================================= error: skipping "/var/log/uucp/Debug" because parent directory has insecure permissions (it's not owned by "root"); consider using "su" directive in config file to tell logrotate which user/group should be used for rotation. error: skipping "/var/log/uucp/Log" because parent directory has insecure permissions (it's not owned by "root"); consider using "su" directive in config file to tell logrotate which user/group should be used for rotation. error: skipping "/var/log/uucp/Stats" because parent directory has insecure permissions (it's not owned by "root"); consider using "su" directive in config file to tell logrotate which user/group should be used for rotation. error: skipping "/var/log/uucp/errors" because parent directory has insecure permissions (it's not owned by "root"); consider using "su" directive in config file to tell logrotate which user/group should be used for rotation. error: skipping "/var/log/uucp/info" because parent directory has insecure permissions (it's not owned by "root"); consider using "su" directive in config file to tell logrotate which user/group should be used for rotation. error: skipping "/var/log/uucp/warnings" because parent directory has insecure permissions (it's not owned by "root"); consider using "su" directive in config file to tell logrotate which user/group should be used for rotation. =8<======================================================================= Полиси гласит: =8<======================================================================= Пакеты не должны содержать каталоги, принадлежащие псевдо-пользователям. Вместо этого следует использовать каталоги, принадлежащие root, с установленным sticky bit и доступом группы по записи. =8<======================================================================= Таким образом, пользователи пакетов postfix, openvpn, nut-server и, видимо, всех реализации syslog, установившие новый logrotate, сейчас каждый день получают такие вот письма. P.S.: предыстория здесь: https://bugzilla.altlinux.org/show_bug.cgi?id=31623 P.P.S.: согласно определению ldv в багтрекере, пакеты нарушающие SPP это блокер для выпуска продуктов, основанных на сизифе (цитата не дословная).
(In reply to comment #0) > Пакет нарушает ALT Secure Packaging Policy, на что ежедневно в почту жалуется > logrotate (3.9.1-alt2 и выше): > > =8<======================================================================= > error: skipping "/var/log/uucp/Debug" because parent directory has insecure > permissions (it's not owned by "root"); consider using "su" directive in config > file to tell logrotate which user/group should be used for rotation. > error: skipping "/var/log/uucp/Log" because parent directory has insecure > permissions (it's not owned by "root"); consider using "su" directive in config > file to tell logrotate which user/group should be used for rotation. > error: skipping "/var/log/uucp/Stats" because parent directory has insecure > permissions (it's not owned by "root"); consider using "su" directive in config > file to tell logrotate which user/group should be used for rotation. Какой софт создает эти три файла? Если изменим владельца каталога, кто-нибудь потеряет туда доступ?
Создаёт пакет uucp: =8<===================================================== evg@thinkpad ~ $egrep '/var/log/uucp/[A-Z]' RPM/contents_index.* RPM/contents_index.x86_64:/var/log/uucp/Debug uucp RPM/contents_index.x86_64:/var/log/uucp/Log uucp RPM/contents_index.x86_64:/var/log/uucp/Stats uucp =8<===================================================== Видимо, потеряет. Возможно, его потребуется обновить.
Впрочем, судя по правам на исполнимые файлы пакета uucp мне кажется что смена прав на root:uucp ничего не сломает: =8<=========================================================================== root@thinkpad ~ #rpm -qvl uucp |egrep -v "^d"|awk '{print $9}'|xargs egrep -c "\b(Stats|Debug)\b"|egrep -iv :0$ |grep -v /usr/share/doc/uucp|aw k -F: '{print $1}'|xargs ls -l |sort -r-s--s--x 1 uucp uucp 47648 Apr 19 2013 /usr/bin/uuname -r-s--s--x 1 uucp uucp 113504 Apr 19 2013 /usr/bin/uucp -r-s--s--x 1 uucp uucp 117592 Apr 19 2013 /usr/bin/uux -r-s--s--x 1 uucp uucp 125880 Apr 19 2013 /usr/bin/uustat -r-s--s--x 1 uucp uucp 129944 Apr 19 2013 /usr/sbin/uuxqt -r-s--s--x 1 uucp uucp 162968 Apr 19 2013 /usr/bin/cu -r-s--s--x 1 uucp uucp 283576 Apr 19 2013 /usr/sbin/uucico -rwxr-xr-x 1 root root 80448 Apr 19 2013 /usr/bin/uulog -rwxr-xr-x 1 root root 88744 Apr 19 2013 /usr/bin/uupick -rwxr-xr-x 1 root root 92512 Apr 19 2013 /usr/sbin/uuchk -rwxr-xr-x 1 root root 92536 Apr 19 2013 /usr/sbin/uuconv =8<=========================================================================== В любом случае, насколько я понимаю, у пакета uucp на порядки меньше пользователей чем у syslog-common, так что было бы оправдано привести syslog-common к SPP даже ценой поломки uucp (который можно починить без спешки после). Я попробовал собрать syslog-common согласно SPP, код у меня в git, бранч bug-31636 (http://git.altlinux.org/people/evg/packages/?p=sysklogd.git;a=commitdiff;h=10e85d118934593ec886df799c1aa735bcc435bf). На моих машинах это вроде бы починило данный баг. Но надо учитывать, что uucp полноценно протестировать мне просто не на чем (он у меня стоит исторически ради программы cu). Прошу проверить/поругать/собрать/дать ACL/...
(In reply to comment #3) > Впрочем, судя по правам на исполнимые файлы пакета uucp мне кажется что смена > прав на root:uucp ничего не сломает: > > =8<=========================================================================== > root@thinkpad ~ #rpm -qvl uucp |egrep -v "^d"|awk '{print $9}'|xargs egrep -c > "\b(Stats|Debug)\b"|egrep -iv :0$ |grep -v /usr/share/doc/uucp|aw > k -F: '{print $1}'|xargs ls -l |sort > -r-s--s--x 1 uucp uucp 47648 Apr 19 2013 /usr/bin/uuname > -r-s--s--x 1 uucp uucp 113504 Apr 19 2013 /usr/bin/uucp > -r-s--s--x 1 uucp uucp 117592 Apr 19 2013 /usr/bin/uux > -r-s--s--x 1 uucp uucp 125880 Apr 19 2013 /usr/bin/uustat > -r-s--s--x 1 uucp uucp 129944 Apr 19 2013 /usr/sbin/uuxqt > -r-s--s--x 1 uucp uucp 162968 Apr 19 2013 /usr/bin/cu > -r-s--s--x 1 uucp uucp 283576 Apr 19 2013 /usr/sbin/uucico > -rwxr-xr-x 1 root root 80448 Apr 19 2013 /usr/bin/uulog > -rwxr-xr-x 1 root root 88744 Apr 19 2013 /usr/bin/uupick > -rwxr-xr-x 1 root root 92512 Apr 19 2013 /usr/sbin/uuchk > -rwxr-xr-x 1 root root 92536 Apr 19 2013 /usr/sbin/uuconv > =8<=========================================================================== > > В любом случае, насколько я понимаю, у пакета uucp на порядки меньше > пользователей чем у syslog-common, так что было бы оправдано привести > syslog-common к SPP даже ценой поломки uucp (который можно починить без спешки > после). > > Я попробовал собрать syslog-common согласно SPP, код у меня в git, бранч > bug-31636 > (http://git.altlinux.org/people/evg/packages/?p=sysklogd.git;a=commitdiff;h=10e85d118934593ec886df799c1aa735bcc435bf). > На моих машинах это вроде бы починило данный баг. Но надо учитывать, что uucp > полноценно протестировать мне просто не на чем (он у меня стоит исторически > ради программы cu). Прошу проверить/поругать/собрать/дать ACL/... У меня это изменение, пожалуй, ничего не сломает, но ведь у меня и пакет uucp не установлен. Давайте лучше спросим мантейнера пакета uucp.
Я думал, у пакета uucp есть/остались только пользователи :-)
(In reply to comment #5) > Я думал, у пакета uucp есть/остались только пользователи :-) Остались пользователи? Да вы, оказывается, оптимист!
Я, например (за счёт программы cu).
ого, я оказывается майнтайнер программы cu. а давайте я её отдельно запакую
ping?
cu теперь в отдельном подпакете. Дмитрий, как насчёт предложенного изменения в sysklogd?
*** Bug 32011 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > *** Bug 32011 has been marked as a duplicate of this bug. *** Может, добавить su в секцию ротации для uucp, а дальше решать, что и как делать по-правильному ? Что-то делать уже надо, p8 выпускать в таком виде странно.
(In reply to comment #6) > > Я думал, у пакета uucp есть/остались только пользователи :-) > > Остались пользователи? Да вы, оказывается, оптимист! Кстати, можно просто убрать упоминание uucp из syslog-common, а на uucp повесить баг о необходимости решить вопрос с логами со ссылкой на этот баг. Пусть с ним мантейнер uucp разбирается, если объявится.
Открыл для себя ckermit. Но всё же: ldv@, ping?
(In reply to comment #13) > (In reply to comment #6) > > > > Я думал, у пакета uucp есть/остались только пользователи :-) > > > > Остались пользователи? Да вы, оказывается, оптимист! > > Кстати, можно просто убрать упоминание uucp из syslog-common, а на uucp > повесить баг о необходимости решить вопрос с логами со ссылкой на этот баг. > Пусть с ним мантейнер uucp разбирается, если объявится. Или сделать комплексно: uucp из syslog-common убрать, одновременно в uucp упаковать /var/log/uucp в том виде, как оно сейчас в syslog-common и добавить правило для logrotate c su: /var/log/uucp/* { su uucp adm rotate 5 weekly postrotate /sbin/reload-syslog >/dev/null endscript } И можно отметить багом на пакет uucp, что надо понять, что с этим делать.
у меня на всех repo нодах этот баг:( забивает почту мусором, что неприятно, так как почта - один из индикаторов проблем с нодой. Проблема, как я понимаю в жестком acl=ldv. Дмитрий, вы будете чинить или поручите кому?
(In reply to comment #16) > у меня на всех repo нодах этот баг:( > забивает почту мусором, что неприятно, так как почта - один из индикаторов > проблем с нодой. > > Проблема, как я понимаю в жестком acl=ldv. > > Дмитрий, вы будете чинить или поручите кому? Пакет syslog-common происходит из исходного пакета sysklogd, в котором есть более важные проблемы, требующие решения. Одна из них - починить собираемость пакета. В принципе понятно, как эти проблемы решать, но не вполне понятно, кто и когда это будет делать.
(In reply to comment #17) > (In reply to comment #16) > > Проблема, как я понимаю в жестком acl=ldv. > > Дмитрий, вы будете чинить или поручите кому? > Пакет syslog-common происходит из исходного пакета sysklogd, в котором есть > более важные проблемы, требующие решения. Одна из них - починить собираемость > пакета. В принципе понятно, как эти проблемы решать, но не вполне понятно, кто > и когда это будет делать. возможно, стоит тогда acl открыть? чтобы если кому припечет, не жаловались, а могли исправить.
*** Bug 32822 has been marked as a duplicate of this bug. ***
(In reply to comment #17) > В принципе понятно, как эти проблемы решать, но не вполне понятно, кто > и когда это будет делать. Похоже, кто-то нашёлся: git://git.altlinux.org/people/boyarsh/packages/sysklogd.git Я себе собрал. Делает вид, что работает.
Очень похоже, что пользователей пакета logrotate нет, или им cron не передаёт каждый час привет от logrotate.
Антон, а какие препятствия мешают sysklogd 1.4.1-alt31 в Сизиф отправить?
А он не пересобирался после обновления glibc. По этой части уже предприняты необходимые действия, но до сизифа результат ещё не добрался.
(В ответ на комментарий №23) > А он не пересобирался после обновления glibc. По этой части уже предприняты > необходимые действия, но до сизифа результат ещё не добрался. Посмотрел, что версия 1.4.1 прожила лет 17. С такими масштабами в ближайшие лет 5 ждать обновления даже в Сизифе не стоит.
(В ответ на комментарий №24) > С такими масштабами в ближайшие лет 5 ждать обновления даже в Сизифе не стоит. Думаю, к p9 всё-таки неизбежно придётся починить.
(In reply to comment #23) > А он не пересобирался после обновления glibc. По этой части уже предприняты > необходимые действия, но до сизифа результат ещё не добрался. Может в p8 хотябы ?
(In reply to comment #26) > > А он не пересобирался после обновления glibc. По этой части уже предприняты > > необходимые действия, но до сизифа результат ещё не добрался. > > Может в p8 хотябы ? А, так надо как-то версию в Сизифе вырастить...
В случае отсутствия реакции мейнтейнера на ошибки с серьёзностью Blocker в bugzilla.altlinux.org в течение 12 часов следует добавить комментарий к ошибке с запросом на NMU и подготовить обновление. Одновременно с заливкой NMU рекомендуется указать мейнтейнеру на git с исправлением (если мейнтейнер использует gear) либо приложить к ошибке в bugzilla.altlinux.org патч. https://www.altlinux.org/NMU Если исправление пакета готово, подготовьте task и напишите запрос на NMU.
(In reply to comment #28) > Если исправление пакета готово, подготовьте task и напишите запрос на NMU. Проблема в том, что во всех репозиториях (как минимум от p5/5.1 и новее) версия sysklogd 1.4.1-alt30. В p8 он бы собрался, но невозможно сделать версию для p8 больше p7 и меньше Sisyphus. А в Sisyphus краткий момент возможности пересобрать упущен: Comment #23
syslog-common-2-alt1 -> sisyphus: * Tue Aug 28 2018 Dmitry V. Levin <ldv@altlinux> 2-alt1 - Split syslog-common out of sysklogd package. - Moved /etc/syslog.d to filesystem package. - Fixed /var/log/uucp permissions (closes: #31636).
Ура, три года почти.
(In reply to Michael Shigorin from comment #23) > А он не пересобирался после обновления glibc. По этой части уже предприняты > необходимые действия, но до сизифа результат ещё не добрался. Немного может быть поздно, но может имеет смысл отправить sysklogd 1.4.1-alt31 в p8, раз пакет теперь уже отсутствует в более свежих репозиториях?
