This happens with all cells after installing kafs-client and then starting afs.mount I can see the cell in "ls /afs" (along with others) $ ls -ld /afs/openstack.org dr-xr-xr-x. 2 root root 0 May 18 14:29 /afs/openstack.org But any access just says $ ls /afs/openstack.org ls: cannot open directory '/afs/openstack.org': Destination address required $ ls /afs/grand.central.org ls: cannot open directory '/afs/grand.central.org': Destination address required kafs-check-config seems to have found all the SRV records correctly $ kafs-check-config openstack.org === Found cell openstack.org === - show-cell=no - status: good, from SRV - VLSERVER afsdb02.openstack.org [good; nss] - udp - port 7003, pref 10, weight 10 - address 23.253.200.228 - VLSERVER afsdb01.openstack.org [good; nss] - udp - port 7003, pref 10, weight 10 - address 104.130.136.20 - VLSERVER afsdb03.openstack.org [good; nss] - udp - port 7003, pref 10, weight 10 - address 104.130.158.72 Reproducible: Always Steps to Reproduce: 1. install kafs-client 2. start afs.mount 3. ls /afs/<something>
This is likely a problem caused by a selinux policy added in fc38 to protect request-key. kafs-client installs /etc/request-key.d/kafs_dns.conf $ cat /etc/request-key.d/kafs_dns.conf create dns_resolver afsdb:* * /usr/libexec/kafs-dns %k and the request to resolve the cell location fails when selinux in enforcing mode.
Yep, that's right now I look --- # sealert -l 95160b35-fc8c-40f8-82a1-7411522e98ee SELinux is preventing request-key from execute access on the file /usr/libexec/kafs-dns. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that request-key should be allowed execute access on the kafs-dns file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'request-key' --raw | audit2allow -M my-requestkey # semodule -X 300 -i my-requestkey.pp Additional Information: Source Context system_u:system_r:keyutils_request_t:s0 Target Context system_u:object_r:bin_t:s0 Target Objects /usr/libexec/kafs-dns [ file ] Source request-key Source Path request-key Port <Unknown> Host fedora19 Source RPM Packages Target RPM Packages kafs-client-0.4-8.fc38.x86_64 SELinux Policy RPM selinux-policy-targeted-38.15-1.fc38.noarch Local Policy RPM selinux-policy-targeted-38.15-1.fc38.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name fedora19 Platform Linux fedora19 6.3.4-201.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Sat May 27 15:08:36 UTC 2023 x86_64 Alert Count 24 First Seen 2023-05-18 13:30:19 AEST Last Seen 2023-06-09 10:04:20 AEST Local ID 95160b35-fc8c-40f8-82a1-7411522e98ee Raw Audit Messages type=AVC msg=audit(1686269060.1:6101): avc: denied { execute } for pid=917200 comm="request-key" name="kafs-dns" dev="dm-1" ino=786742 scontext=system_u:system_r:keyutils_request_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file permissive=1 Hash: request-key,keyutils_request_t,bin_t,file,execute --- Flipping to "setenforce 0" and I can open the directory just fine
I guess the question is whether kafs-dns should be in the base policy or be added by the kafs-client package.
I created a local TE file. I'm not sure it's exactly right but @Ian's initial repo works as expected with it loaded [tony@thor ~]$ sudo cat /etc/selinux/local/kafs.request-key.te module kafs.request-key 3.0; require { type kernel_t; type bin_t; type keyutils_request_t; type net_conf_t; class file { execute execute_no_trans map read }; class lnk_file read; class udp_socket create; class key setattr; } #============= keyutils_request_t ============== allow keyutils_request_t bin_t:file { execute execute_no_trans }; allow keyutils_request_t bin_t:file map; allow keyutils_request_t kernel_t:key setattr; allow keyutils_request_t net_conf_t:file read; allow keyutils_request_t net_conf_t:lnk_file read; allow keyutils_request_t self:udp_socket create;
Ian, Could you try the following scratchbuild? https://github.com/fedora-selinux/selinux-policy/pull/1750 Checks -> Artifacts -> rpms.zip
(In reply to Zdenek Pytela from comment #5) > Ian, > > Could you try the following scratchbuild? > > https://github.com/fedora-selinux/selinux-policy/pull/1750 > Checks -> Artifacts -> rpms.zip Works for me on f38; no AVCs are logged in permissive mode, and the afs dynamic root works as expected in enforcing mode.
(In reply to Marc Dionne (Auristor) from comment #6) > Works for me on f38; no AVCs are logged in permissive mode, and the afs > dynamic root works as expected in enforcing mode. Thanks for confirming.
FEDORA-2023-ba070ee6ba has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-ba070ee6ba
FEDORA-2023-ba070ee6ba has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-ba070ee6ba` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-ba070ee6ba See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-ba070ee6ba has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.