Fusex kerberos authentication inside docker for version v4.4.18+

Site Administrators
1

Hello,

We noticed that after version 4.4.10 of fusex client, the way we were authenticating user via kerberos inside containers do not work any more.

We currently successfully run unprivileged docker containers mounting shared eosd and authentication using kerberos ticket loaded with eosfusebind -g. As long as the userid inside the docker matches the userid on the host, this works, like this :

# su testproc -c "cat /eos/jeodpp/proc/whoami"
Virtual Identity: uid=35575 (35575,99) gid=41068 (99,41068,50008) [authz:krb5] host=... geo-location=JRC
# docker run  -v /eos/:/eos/ debian bash -c "useradd -u 35575 testproc; su testproc -c 'cat /eos/jeodpp/proc/whoami'"
Virtual Identity: uid=35575 (35575,99) gid=41068 (99,41068,50008) [authz:krb5] host=... geo-location=JRC

We successfully tried the same with eosxd until v 4.4.10 volumes, but when upgrading to fusex v4.4.18, 4.4.23 or even latest testing one 4.4.45, it doesn’t work any more, even when setting correctly the KRB5CCNAME variable. The client just acts as if no ticket were available : eos content is accessible, but with a nobody (99,99) authentication :

# su testproc -c "cat /eos/jeodpp/proc/whoami"
Virtual Identity: uid=35575 (35575,99) gid=41068 (99,41068,50008) [authz:krb5] host=... geo-location=JRC
# docker run  -v /eos/:/eos/ debian bash -c "useradd -u 35575 testproc; su testproc -c 'cat /eos/jeodpp/proc/whoami'"
Virtual Identity: uid=99 (99) gid=99 (99) [authz:unix] host=... geo-location=JRC

Was there some regression ? Or was it a bug, not a feature, that we were taking advantage of, and that was corrected ? If yes, what could be the correct way to restore the kerberos authentication inside docker container with the last versions of fusex client ?

2

Hi Franck,

Indeed there has been a change in functionality - now, paths are translated in the context of the container issuing requests to eosxd, not the context of eosxd itself.

Example - a process has KRB5CCNAME=/tmp/ticket in its environment. Previously, /tmp/ticket as found on the container (or host) running the eosxd process was used, not /tmp/ticket as found on the container of the process accessing the filesystem.

Now is the opposite - every container is isolated by default, and unable to access a security ticket which resides outside of its namespace context.

To return to the previous behaviour: Set ignore-containerization to 1 in the auth section of configuration:

  "auth" : {
    ....
    "ignore-containerization" : 1,
   ...
  }
3

Thank you very much for this precise answer, Giorgos!

That means also that we can now place the tickets only inside the container using it, sounds handy and more secure. And thanks for this ignore-containerization option that will help us during the transition.