Bug#886548: libreoffice-common: Try to ship all AppArmor profiles in enforce mode
[ I know this, maybe you should Cc the submitter? n...@bugs.debian.org does NOT go to the submitter ] Hi, On Fri, Feb 23, 2018 at 03:23:12PM +0100, Olivier Tilloy wrote: > Note that ubuntu accidentally shipped the apparmor profiles in enforce > mode for 5.4.5 on 17.10 as part of a stable release update, and we > have been getting rather negative feedback as this broke numerous real > use cases. See https://launchpad.net/bugs/1751005. Rico pointed me to this bug this morning: /home2 is not a real use case imho, some of things in this bug is, yes.. But yeah, stuff like this is what I meant in previous replies. There's also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887593 (mostly fixed, except the OpenCL stuff, firefox 58 - cert9 - support not yet uploaded, pdfimport w support and "File -> Sign existing PDF" probably also is still broken. ) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882597 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884747 (closed since it went from enforce to disabled) And all the other fixes (mozilla, gpg, your senddoc fixes, ..) were never backported to 5.4.x anyways, I only maintain 6.x by now. :) Regards, Rene >
Bug#886548: libreoffice-common: Try to ship all AppArmor profiles in enforce mode
Note that ubuntu accidentally shipped the apparmor profiles in enforce mode for 5.4.5 on 17.10 as part of a stable release update, and we have been getting rather negative feedback as this broke numerous real use cases. See https://launchpad.net/bugs/1751005.
Bug#886548: libreoffice-common: Try to ship all AppArmor profiles in enforce mode
Hi,
On Sun, Jan 07, 2018 at 03:40:55PM +0100, intrig...@debian.org wrote:
> The remaining blocker seems to be autopkgtests being broken by
> AppArmor, due to using custom paths:
Bascially anything which needs "custom" paths. Another incarnation of
this was https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884747
> How about this:
>
> 1. Add the needs-root restriction to debian/tests/control (and
>possibly the breaks-testbed restriction too if we cannot reliably
>revert the following changes after running the tests).
And run the tests as root?
> 2. Wrap the test cases with code that modifies the @{libo_user_dirs}
>AppArmor profile variable to include the place where the test cases
>will store their custom data directories, and then reloads the
>affected AppArmor profile.
>
> Another option is to do (1) but instead of (2), disable the AppArmor
> profiles that break the test suite. It would obviously be cheaper and
> more reliable, and I'd be happy to give it a try (no big hurry
> though). But it won't exercise the AppArmor policy contrary to the
> solution proposed above. But surely it would be a nice first iteration
> until someone feels like implementing the more advanced solution
> proposed above.
>
> What do you think?
That would probably work, but still cause #884747 (and whatever else still
unreported).
Regards,
Rene
Bug#886548: libreoffice-common: Try to ship all AppArmor profiles in enforce mode
Package: libreoffice-common
Version: 1:5.4.4-1
Severity: wishlist
Hi,
libreoffice-common 1:5.4.4-1 stopped disabling all profiles but the
oosplash and soffice.bin profiles are still shipped in complain mode.
This bug report is meant to track and discuss what needs to be done to
ship them in enforce mode instead. See #883800 for the beginning of
this conversation.
The remaining blocker seems to be autopkgtests being broken by
AppArmor, due to using custom paths:
René Engelhard wrote:
> intrigeri wrote:
>> You mentioned something elsewhere about the LibreOffice test suite
>> being possibly affected by this change. Could you please point me at
>> an example of this problem? I could investigate. In general, test
> I've not *seen* this problem yet, but I can imagine it/foresee it.
>> AppArmor policy. Now, runtime tests such as autopkgtests may be
>> affected; if needed I could take a look.
> Exactly.
> From
> https://ci.debian.net/data/autopkgtest/unstable/amd64/libr/libreoffice/20171206_231513/log.gz:
> [...]
> [build JUT] sc_unoapi_6
> S=/tmp/autopkgtest-lxc.tpv162wi/downtmp/build.hf5/src && I=$S/instdir &&
> W=$S/workdir && rm -rf $W/JunitTest/sc_unoapi_6/user && mkdir -p
> $W/JunitTest/sc_unoapi_6/user/user && cp
> $S/qadevOOo/qa/registrymodifications.xcu
> $W/JunitTest/sc_unoapi_6/user/user/ &&
> (/usr/lib/jvm/default-java/bin/java -Xmx64M -classpath
> "$W/JavaClassSet/JunitTest/sc_unoapi_6:/usr/share/java/junit4.jar:/lib::/usr/lib/libreoffice/program/classes/jurt.jar:/usr/lib/libreoffice/program/classes/test.jar:/usr/lib/libreoffice/program/classes/ScriptProviderForJava.jar:/usr/lib/libreoffice/program/classes/XMergeBridge.jar:/usr/lib/libreoffice/program/classes/xmerge.jar:/usr/lib/libreoffice/program/classes/ridl.jar:/usr/lib/libreoffice/program/classes/test-tools.jar:/usr/lib/libreoffice/program/classes/unoloader.jar:/usr/lib/libreoffice/program/classes/report.jar:/usr/lib/libreoffice/program/classes/unoil.jar:/usr/lib/libreoffice/program/classes/hsqldb.jar:/usr/lib/libreoffice/program/classes/table.jar:/usr/lib/libreoffice/program/classes/smoketest.jar:/usr/lib/libreoffice/program/classes/ScriptFramework.jar:/usr/lib/libreoffice/program/classes/java_uno.jar:/usr/lib/libreoffice/program/classes/ConnectivityTools.jar:/usr/lib/libreoffice/program/classes/query.jar:/usr/lib/libreoffice/program/classes/OOoRunner.jar:/usr/lib/libreoffice/program/classes/sdbc_hsqldb.jar:/usr/lib/libreoffice/program/classes/juh.jar:/usr/lib/libreoffice/program/classes/form.jar:/usr/lib/libreoffice/program/classes/commonwizards.jar"
> -Dorg.openoffice.test.arg.env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
> -Dorg.openoffice.test.arg.user=file://$W/JunitTest/sc_unoapi_6/user
> -Dorg.openoffice.test.arg.workdir=$W/JunitTest/sc_unoapi_6/user
> -Dorg.openoffice.test.arg.postprocesscommand=$S/solenv/bin/gdb-core-bt.sh
> -Dorg.openoffice.test.arg.soffice="path:/usr/lib/libreoffice/program/soffice"
> -Djava.library.path=/usr/lib/ure/lib
> -Dorg.openoffice.test.arg.sce=$S/sc/qa/unoapi/sc_6.sce
> -Dorg.openoffice.test.arg.tdoc=$S/sc/qa/unoapi/testdocuments
> -Dorg.openoffice.test.arg.xcl=$S/sc/qa/unoapi/knownissues.xcl
> org.junit.runner.JUnitCore org.openoffice.test.UnoApiTest >
> $W/JunitTest/sc_unoapi_6/done.log 2>&1 || (cat
> $W/JunitTest/sc_unoapi_6/done.log && echo "to rerun just this failed
> test without all others, run:" && echo && echo "make
> JunitTest_sc_unoapi_6" && echo && echo "cd into the module dir to run
> the tests faster" && echo "Or to do interactive debugging, run two
> shells with:" && echo && echo "make debugrun" && echo "make
> gb_JunitTest_DEBUGRUN=T JunitTest_sc_unoapi_6" && echo && false))
> [...]
> Note e.g. the -Dorg.openoffice.test.arg.user. Similar (more like what
> was in the bug report in the first place) for the C++ (Unit)tests which
> are not (yet) ran in autopkgtest.
> From my current 6.0.0 beta2 testbuild (yes, that is local):
> [build CUT] sw_ooxmlexport4
> S=/data/rene/git/LibreOffice/libreoffice-6-0 && I=$S/instdir &&
> W=$S/workdir &&mkdir -p $W/CppunitTest/ && rm -fr
> $W/CppunitTest/sw_ooxmlexport4.test.user && cp -r $W/unittest
> $W/CppunitTest/sw_ooxmlexport4.test.user &&rm -fr
> $W/CppunitTest/sw_ooxmlexport4.test.core && mkdir
> $W/CppunitTest/sw_ooxmlexport4.test.core && cd
> $W/CppunitTest/sw_ooxmlexport4.test.core && (
> LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
> MALLOC_CHECK_=2 MALLOC_PERTURB_=153
> $W/LinkTarget/Executable/cppunittester
> $W/LinkTarget/CppunitTest/libtest_sw_ooxmlexport4.so --headless
> "-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
> "-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
> "-env:UserInstallation=file://$W/CppunitTest/sw_ooxmlexport4.test.user"
> [...]
How about this:
1. Add the needs-root restriction to debian/tests/control (and
possibly the breaks-testbed restriction too if we cannot reliably
