On ma, 10 touko 2021, Harry G. Coin wrote:
On 5/10/21 8:31 AM, Alexander Bokovoy wrote:
> On su, 09 touko 2021, Harry G. Coin via FreeIPA-users wrote:
>> On f34, freeipa-server 4.9.3-2: Upon choosing any action using a
>> logged-in UI that has been left idle for some hours, browsers lock a
>> display 'internal server error' (at least on firefox) instead of a
>> log-in page, or the desired page. No actions on the server side will
>> clear it. The only work-around is to delete the browser cookies and
>> cached data, and after navigating to the UI the login page appears
>> normally.
>
> It looks like the cache entry for user authentication which is stored
> encrypted on the server side cannot be decrypted anymore. This might
> happen when you have rebooted a server between authenticating the user
> and its session's expiration. There are two keys here:
>
> - mod_auth_gssapi uses ipasession.key (in /etc/httpd/alias in Fedora)
> for encrypting the cookie session
>
> - GSS-Proxy uses own service keytab or an in-memory key to encrypt
> Kerberos credentials in a ccache generated and stored on the server
> which corresponds to the content stored in the cookie session
>
> If you'd restart GSS-Proxy or reboot the system, the ccache generated
> and stored on the server side by GSS-Proxy would not be possible to
> decrypt in case an ephemeral in-memory key was used.
>
> Can you enable IPA server-side debugging in case this happens to see if
> we can handle an error from mod_auth_gssapi better?
>
I think blocking access to the freeipa-ui until all users delete all
browser cookies and cached data every time freeipa is rebooted is
probably not a good thing.
In my test case, freeipa-server is in a VM using a virtio-fs as the
boot/root filesystem. The virtio-fs folks haven't quite managed to
solve SELinux problems when their file system is the root device, so for
the time being I set SELinux to permissive. Serendipity might have
generated a clue, as follows:
# cat /etc/ipa/server.conf
[global]
certmonger_wait_timeout=1200
startup_timeout = 720
startup_traceback = True
debug=True
# journalctl -f
...
May 10 09:33:40
registry1.1.quietfountain.com [1435]: GSSAPI client step 1
May 10 09:33:45
registry1.1.quietfountain.com audit[676]: AVC avc:
denied { lock } for pid=676 comm="gssproxy"
path="/var/lib/ipa/gssproxy/http.keytab" dev="virtiofs" ino=745470
scontext=system_u:system_r:gssproxy_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
permissive=1
May 10 09:33:46
registry1.1.quietfountain.com [1435]: GSSAPI client step 1
May 10 09:33:46
registry1.1.quietfountain.com [1435]: GSSAPI client step 1
...
It's quite repeatable, every refresh on the browser generates the AVC
line above (amid the log being cluttered with 'GSSAPI client step 1'...
Thanks, this is helpful. In your case /var/lib/ipa/gssproxy/http.keytab
has unlabeled_t context and that access is obviously not allowed.
# ls -lZ /var/lib/ipa/gssproxy/
total 4
-rw-------. 1 apache apache unconfined_u:object_r:ipa_var_lib_t:s0 178 May 7 09:27
http.keytab
Does restorecon help to relable? Perhaps, this is due to installing in
SELinux off?
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland