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
revert the following changes after running the tests).
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?
Cheers,
--
intrigeri
Reply to: