7:14 a.m.
On Thu, Jul 05, 2018 at 11:20:57AM +0300, Alexander Bokovoy wrote:
> the docker 17.09.0-ce behaviour on that system is and if seccomp
can
> somehow be tweaked?
I cannot give you an answer on Ubuntu parts but may be you can instead
remove use of KEYRING ccache from krb5.conf, thus removing the reason
for seccomp modification?
This is not about Kerberos caches using kernel keyring.
This is about session keyring created by systemd:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1691096
https://github.com/systemd/systemd/issues/6281
https://bugzilla.redhat.com/show_bug.cgi?id=1492081
Presumably it assumed that if it can create the keyring, it will be
able to chown it as well, leading to
systemd[593]: pki-tomcatd(a)pki-tomcat.service: Failed at step KEYRING spawning
/usr/sbin/pki-server: Permission denied
On Fedora and RHEL with docker from distribution/Extras, docker is
built and configured to use seccomp, and it prevents it from being
able to being able to create the keyring in the first place, so things
do not fail.
I can reproduce the problem on Fedora for example with
docker run --security-opt=seccomp=unconfined --rm -ti -e DEBUG_NO_EXIT=true -e
PASSWORD=Secret123 -h ipa.example.test freeipa/freeipa-server:fedora-27 -U -r EXAMPLE.TEST
--no-ntp
-- the seccomp=unconfined allows the first operation but due to
lack of CAP_CHOWN, the second one then fails.
I believe Ubuntu used by Travis CI and the docker build that is there
do not support seccomp, so things run similar to seccomp=unconfined
on Fedora.
Container run from the centos-7 image does not fail because systemd there
did not have that logic yet, the fedora-rawhide image does not fail
because the logic in systemd has been fixed since.
--
Jan Pazdziora
Senior Principal Software Engineer, Security Engineering, Red Hat