freeipa

#9198 [Tracker] nightly failure: after ipa trust-add, cred cache contains cifs/master.ipa.test@IPA.TEST instead of admin principal
Closed: fixed by frenaud. Opened by amore.

Closed: fixed
Reopen Issue

Issue

FreeIPA nightly tests fail to add add ipa user. See for instance this test report with the following
test_integration/test_sssd.py::TestSSSDWithAdTrust::test_auth_cache_disabled_by_default[ipa]::setup
report.

Steps to Reproduce

  1. install ipa server with client and establish trust with AD
  2. ipa user-add user2 --first test --last user

Actual behavior

ERROR ipatests.pytest_ipa.integration.host.Host.master.cmd106:host.py:201 stderr: ipa: ERROR: Insufficient access: Could not read UPG Definition originfilter. Check your permissions.

Expected behavior

ipa user-add should succeed.

Version/Release/Distribution

389-ds-base-2.1.3-1.fc36.x86_64
The full package list is available here.

Metadata Update from @amore:
- Issue tagged with: test-failure, tests

The wrong principal was used: cifs/master.ipa.test@IPA.TEST

From the httpd error log:

[Thu Jul 07 11:07:18.975926 2022] [wsgi:error] [pid 20695:tid 21125] [remote 192.168.122.24:36742] ipa: INFO: [jsonserver_kerb] cifs/master.ipa.test@IPA.TEST: user_add/1('user2', givenname='test', sn='user', version='2.249'): ACIError

This test hasn't changed significantly for over a year so I'm not sure why it blew up like this. It can be fixed by putting an explicit kinit admin prior to the user-add though to remove any assumptions about who is doing the add.

Metadata Update from @rcritten:
- Issue assigned to rcritten

https://github.com/freeipa/freeipa/pull/6355

The same issue occurs in test_winsyncmigrate.py::TestWinsyncMigrate::test_migration, where the test is doing
- kinit admin
- ipa trust-add
- ipa-winsync-migrate
and the last call is using cifs/master.ipa.test@IPA.TEST principal instead of admin.

The same issue occurs in test_integration/test_idviews.py::TestCertsInIDOverrides::test_certs_in_idoverrides_ad_users.

There are a ton of NetworkManager AVCs but I suspect it is related to these samba errors:

type=AVC msg=audit(1657297049.998:3704): avc: denied { sendto } for pid=13209 comm="smbcontrol" path="/var/lib/samba/private/msg.sock/13133" scontext=unconfined_u:unconfined_r:smbcontrol_t:s0-s0:c0.c1023 tcontext=system_u:system_r:winbind_rpcd_t:s0 tclass=unix_dgram_socket permissive=0
type=AVC msg=audit(1657297049.998:3705): avc: denied { sendto } for pid=13209 comm="smbcontrol" path="/var/lib/samba/private/msg.sock/13133" scontext=unconfined_u:unconfined_r:smbcontrol_t:s0-s0:c0.c1023 tcontext=system_u:system_r:winbind_rpcd_t:s0 tclass=unix_dgram_socket permissive=0
type=AVC msg=audit(1657297049.998:3706): avc: denied { sendto } for pid=13209 comm="smbcontrol" path="/var/lib/samba/private/msg.sock/13146" scontext=unconfined_u:unconfined_r:smbcontrol_t:s0-s0:c0.c1023 tcontext=system_u:system_r:winbind_rpcd_t:s0 tclass=unix_dgram_socket permissive=0
type=AVC msg=audit(1657297049.998:3707): avc: denied { sendto } for pid=13209 comm="smbcontrol" path="/var/lib/samba/private/msg.sock/13146" scontext=unconfined_u:unconfined_r:smbcontrol_t:s0-s0:c0.c1023 tcontext=system_u:system_r:winbind_rpcd_t:s0 tclass=unix_dgram_socket permissive=0
type=AVC msg=audit(1657297049.999:3708): avc: denied { sendto } for pid=13209 comm="smbcontrol" path="/var/lib/samba/private/msg.sock/13151" scontext=unconfined_u:unconfined_r:smbcontrol_t:s0-s0:c0.c1023 tcontext=system_u:system_r:winbind_rpcd_t:s0 tclass=unix_dgram_socket permissive=0
type=AVC msg=audit(1657297049.999:3709): avc: denied { sendto } for pid=13209 comm="smbcontrol" path="/var/lib/samba/private/msg.sock/13151" scontext=unconfined_u:unconfined_r:smbcontrol_t:s0-s0:c0.c1023 tcontext=system_u:system_r:winbind_rpcd_t:s0 tclass=unix_dgram_socket permissive=0

I added negative karma to https://bodhi.fedoraproject.org/updates/FEDORA-2022-fd22b79a84

Opened BZ https://bugzilla.redhat.com/show_bug.cgi?id=2106006 against fedora 36 / selinux-policy
Edited by amore

Failure is reproduced and new AVC are collected in audit.log
using version selinux-policy-36.13-3.fc36.noarch see installed packages

Opened BZ https://bugzilla.redhat.com/show_bug.cgi?id=2115691 against fedora 36 / selinux-policy
with selinux-policy-36.13-3.fc36.noarch

Metadata Update from @frenaud:
- Issue tagged with: tracker

The issue was seen in the nightlies [testing_ipa-4.9_latest_selinux].
Last run: PR #2118: not seen, with selinux-policy-36.16-1.fc36.noarch
Prev run: PR #2099: seen, with selinux-policy-36.15-1.fc36.noarch.

Summary:
- Fedora 35 is not impacted
- Fedora 36 needs the newest selinux-policy (ipa-4-9 branch and above)
- Fedora 37 not impacted.
We need to bump the selinux-policy version required by freeipa-server on ipa-4-9 branch and above.

Update:
- on RHEL8, the fix is available with selinux-policy 3.14.3-107 (https://bugzilla.redhat.com/show_bug.cgi?id=2117199)
- RHEL9: not available yet (https://bugzilla.redhat.com/show_bug.cgi?id=2114902)
Edited by frenaud

Metadata Update from @frenaud:
- Custom field on_review adjusted to https://github.com/freeipa/freeipa/pull/6518
- Issue assigned to frenaud (was: rcritten)

master:

  • fbda6ea4d35d6500345a5b1a8b44f7dd19484939 Spec file: bump the selinux-policy version

ipa-4-10:

  • 4e201ec97e5c54ad8d5fa02285e628d1a36d9ea7 Spec file: bump the selinux-policy version

ipa-4-9:

  • 58ad9f2eec0afe494c57015c4449ae39748117e4 Spec file: bump the selinux-policy version

Metadata Update from @frenaud:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)
Metadata

test-failure tests tracker

None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.