Bug 34793

Проблеме три недели уже.

я это видел, но сказать по этому поводу мне пока нечего :(

Это не может быть связано с https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886329 ?
То есть сработает ли повторный setfacl?

(В ответ на комментарий №3)
> Это не может быть связано с
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886329 ?
> То есть сработает ли повторный setfacl?

Сколько раз его не используй на один и тот же файл, получаешь:
Operation not supported

Проблема началась после:
2018-04-01 - Kernel Bot <kernelbot@altlinux.org> 1:4.14.32-alt1 - v4.14.32 (Fixes: CVE-2017-8824)

Как воспроизвести проблему командой setfacl?

    1# uname -r -m
    4.16.10-un-def-alt1 x86_64
    1# touch g
    1# setfacl -m m:- g
    1# getfacl g
    # file: g
    # owner: root
    # group: root
    user::rw-
    group::r--                      #effective:---
    mask::---
    other::r--
    1# getfattr -d -m. g
    # file: g
    system.posix_acl_access=0sAgAAAAEABgD/////BAAEAP////8QAAAA/////yAABAD/////

То есть на 4.16.10 проблемы нет?

Проблема только на live, то бишь на squashfs. Воспроизводится на регулярках gnome и xfce, у которых ядро un-def.

Ошибка также пришла и в стартеркиты p8 с ядром 4.14.45-un-def-alt0.M80P.1

squashfs отродясь не поддерживал posix acl.

(В ответ на комментарий №8)
> squashfs отродясь не поддерживал posix acl.

Хорошо, на самой squshfs не поддерживается. Но при загрузке live с ядром std-def операция setfacl работает, а при загрузке live с un-def не поддерживается. Это приводит к недоступности журнала systemd из-под пользователя на live с ядром un-def.

(В ответ на комментарий №8)
> squashfs отродясь не поддерживал posix acl.
aufs на squashfs+tmpfs там...

Надо монтировать aufs с -o acl.

С приходом ядра 4.14.54-std-def-alt1 в Сизиф, проблема касается всех регулярок.

(В ответ на комментарий №12)
> С приходом ядра 4.14.54-std-def-alt1 в Сизиф, проблема касается всех регулярок.
...кроме sysv-based.

#11 не помогает? 
Попробуйте и напишите, пожалуйста.

make-initrd-propagator-0.33-alt2 -> sisyphus:

Wed Jul 11 2018 Anton Midyukov <antohami@altlinux> 0.33-alt2
- Fix ACL access for livecd (Closes: 34793)

2 vt: спасибо; более старые ядра такой опцией подавятся, правильно понимаю?

2 antohami: просьба проверить на p8 с локально подсунутой твоей сборкой m-i-p,
            нет ли в ней скрытой мины -- возможно, надо делать что-то вроде
mount -t aufs none $stage2 -o acl,dirs=$stage2.rw=rw:$stage2.ro=rr ||
  mount -t aufs none $stage2 -o dirs=$stage2.rw=rw:$stage2.ro=rr

Ну и поднимать следовало версию (поскольку менялся код проекта), а не релиз
(это если бы менялись только спек/патчи).

(В ответ на комментарий №16)
> более старые ядра такой опцией подавятся, правильно понимаю?

Не должны, в 4.0 она точно есть.

(В ответ на комментарий №16)
> 2 vt: спасибо; более старые ядра такой опцией подавятся, правильно понимаю?
> 
> 2 antohami: просьба проверить на p8 с локально подсунутой твоей сборкой m-i-p,
>             нет ли в ней скрытой мины -- возможно, надо делать что-то вроде
> mount -t aufs none $stage2 -o acl,dirs=$stage2.rw=rw:$stage2.ro=rr ||
>   mount -t aufs none $stage2 -o dirs=$stage2.rw=rw:$stage2.ro=rr
> 
> Ну и поднимать следовало версию (поскольку менялся код проекта), а не релиз
> (это если бы менялись только спек/патчи).

Проверил собираемость и работоспособность для apt-p8-lxde.iso (ядро 4.9) и altlinux-p7-lxde.iso (ядро 3.14). Проблем нет. Добавлял опцию acl в пакеты, которые в репозиториях p8 и p7, поднимая релиз. Завтра могу ещё p6 проверить (ядро 3.0), и попытаться собрать на p5 (ядро 2.32).

Проверил p6 (ядро 3.0) собрал livecd-icewm.iso. При загрузке ругается на плохую опцию. Ядро 3.0 точно не поддерживает опцию ACL. 3.14 поддерживает. Поддержка какой минимальной версии ядра нужна в Сизифе/p9 ?

(В ответ на комментарий №19)
> Проверил p6 (ядро 3.0) собрал livecd-icewm.iso. При загрузке ругается на плохую
> опцию. Ядро 3.0 точно не поддерживает опцию ACL. 3.14 поддерживает. Поддержка
> какой минимальной версии ядра нужна в Сизифе/p9 ?

опцию acl

(В ответ на комментарий №19)
> Проверил p6 (ядро 3.0) собрал livecd-icewm.iso. При загрузке ругается на плохую
> опцию. Ядро 3.0 точно не поддерживает опцию ACL. 3.14 поддерживает. Поддержка
> какой минимальной версии ядра нужна в Сизифе/p9 ?

В худшем случае должно работать на std-def.
В лучшем случае -- на самом старом ядре, которое есть в данном репозитории, но это не обязательно.

(В ответ на комментарий №21)
> (В ответ на комментарий №19)
> > Проверил p6 (ядро 3.0) собрал livecd-icewm.iso. При загрузке ругается на плохую
> > опцию. Ядро 3.0 точно не поддерживает опцию ACL. 3.14 поддерживает. Поддержка
> > какой минимальной версии ядра нужна в Сизифе/p9 ?
> 
> В худшем случае должно работать на std-def.
> В лучшем случае -- на самом старом ядре, которое есть в данном репозитории, но
> это не обязательно.

Старички только:
kernel-image-domU-ovz-el-2.6.32-alt162
kernel-image-ovz-el-2.6.32-alt162

Им поддержка propagator нужна?
Для других платформ (эльбрус, mips) ядра древнее 3.14 не используются?

Добавить workaround не проблема:
mount -t aufs none $stage2 -o acl,dirs=$stage2.rw=rw:$stage2.ro=rr ||
  mount -t aufs none $stage2 -o dirs=$stage2.rw=rw:$stage2.ro=rr

Проверял, работает.

> Старички только:
> kernel-image-domU-ovz-el-2.6.32-alt162
> kernel-image-ovz-el-2.6.32-alt162
Вряд ли на них будут делаться установщики. Кроме того, может оказаться, что в этих ядрах работает -o acl, так как это совсем не те версии, которыми кажутся.

> Для других платформ (эльбрус, mips) ядра древнее 3.14 не используются?
Насколько я знаю, нет.

(В ответ на комментарий №23)
> > Старички только:
> > kernel-image-domU-ovz-el-2.6.32-alt162
> > kernel-image-ovz-el-2.6.32-alt162
> Вряд ли на них будут делаться установщики. Кроме того, может оказаться, что в
> этих ядрах работает -o acl, так как это совсем не те версии, которыми кажутся.
> 
> > Для других платформ (эльбрус, mips) ядра древнее 3.14 не используются?
> Насколько я знаю, нет.

Точно нет. Думаю, что на этом можно закрывать обсуждение. Спасибо !

Жаль, что тогда же не озадачились бэкпортом в p8, вылезло на альфе стартеркитов; сейчас он ждёт в http://webery.altlinux.org/task/212500, sotor@ в курсе.

(В ответ на комментарий №25)
> http://webery.altlinux.org/task/212500
Там же перенос строки надо эскейпить после "||".

(В ответ на комментарий №26)
> (В ответ на комментарий №25)
> > http://webery.altlinux.org/task/212500
> Там же перенос строки надо эскейпить после "||".

Ага. Но тестировавший человек проблемы не обнаружил. Я исправил. Спасибо. Вчера тупо скопировал отсюда строчки, так как торопился...

(В ответ на комментарий №26)
> Там же перенос строки надо эскейпить после "||".
Нет; не пугай людей.

PS: уехало в p8.

(В ответ на комментарий №28)
> > Там же перенос строки надо эскейпить после "||".
> Нет
Не "нет", а "уже нет". ;-)

Я вообще для красоты подобние пишу в виде
something \
  || something

(В ответ на комментарий №29)
> > > Там же перенос строки надо эскейпить после "||".
> > Нет.
> Не "нет", а "уже нет". ;-)
Просто _нет_.  Ты хоть сам бы проверил, прежде чем народ смущать.
Тем более когда уже прямым текстом сказано ;-)

(В ответ на комментарий №30)
> Я вообще для красоты подобние пишу в виде
> something \
>   || something
Сам обычно пишу

a || b

или реже

a || \
  b

или порой по-легионовски

a ||
  b

А варианты вроде

a \
&& b \
|| c

последние годы стал сразу писать if-then-else (у чего есть ещё отличие в поведении по части кода возврата последней команды).

Но вкусовщина вкусовщиной, я бухтел против введения в заблуждение.

(В ответ на комментарий №31)
> я бухтел против введения в заблуждение.
Дык, я начал с этого. ;-)