Bug 31636
| Summary: | Нарушает ALT Secure Packaging Policy | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Evgenii Terechkov <evg> |
| Component: | syslog-common | Assignee: | placeholder <placeholder> |
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
| Severity: | blocker | ||
| Priority: | P3 | CC: | aen, asy, boyarsh, glebfm, gremlin, lav, ldv, mike, placeholder, sbolshakov, taf, viy, vseleznv |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
| URL: | https://www.altlinux.org/Secure_Packaging_Policy | ||
| Bug Depends on: | |||
| Bug Blocks: | 30940, 34231 | ||
(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, раз пакет теперь уже отсутствует в более свежих репозиториях? |
Description
Evgenii Terechkov 2015-12-17 08:00:21 MSK