Bug 31636

(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, раз пакет теперь уже отсутствует в более свежих репозиториях?