Description of problem: Since v220 this patch seems to no longer do what it advertises: https://github.com/systemd/systemd/commit/a8828ed93878b4b4866d40ebfb660e54995ff72e Jun 16 16:11:37 d30 systemd-nspawn[13366]: setexeccon("system_u:system_r:refpolicy_subject_t") failed: No such file or directory Version-Release number of selected component (if applicable): v220 How reproducible: Quote from original patch commit message: " For example if you wanted to wrap an container with SELinux sandbox labels, you could execute a command line the following chcon system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -R /srv/container systemd-nspawn -L system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -Z system_u:system_r:svirt_lxc_net_t:s0:c0,c1 -D /srv/container /bin/sh " Actual results: failed: No such file or directory Expected results: systemd[1]: Started $CONTAINER_DESCRIPTION...
This is supposedly due to a bug in libselinux: 09:36 <tfirg_> hi 09:36 <tfirg_> https://bugzilla.redhat.com/show_bug.cgi?id=1232371 09:37 <tfirg_> i think setexeccon() is called in the wrong way there, but i am not sure 09:37 <tfirg_> if that is the case then the fix should be pretty easy 09:39 <tfirg_> if (setexeccon((security_context_t) arg_selinux_context) < 0) 09:39 <tfirg_> i dont think that setexeccon() is supposed to be called like that? 09:41 <tfirg_> shouldnt it be something like this instead? if (setexeccon(arg_selinux_context) < 0) 09:56 <mgrepl> do you have a commit number for this change? 10:16 <tfirg_> https://github.com/systemd/systemd/commit/c74e630d0ce4b1ace116e8211f3b6eb472efa7e3 10:16 <tfirg_> that is where : if (setexeccon(arg_selinux_context) < 0) 10:16 <tfirg_> is changed to: if (setexeccon((security_context_t) arg_selinux_context) < 0) 10:19 <tfirg_> -static char *arg_selinux_context = NULL; 10:19 <tfirg_> -static char *arg_selinux_apifs_context = NULL; 10:19 <tfirg_> +static const char *arg_selinux_context = NULL; 10:19 <tfirg_> +static const char *arg_selinux_apifs_context = NULL; 10:19 <tfirg_> not sure how that affects things, but its probably related 10:33 <tfirg_> the functionality may have been broken even before that commit, but my gut feeling tells me that this commit broken it 10:42 <mgrepl> well I will have time later today but yes it relates with security_context_t and a string handling here 10:43 <tfirg_> if you can' t get to it then please tell me so, i can also ask ssmalley for advice if needed 11:27 <mgrepl> what is your version of libselinux? I probably see it 11:27 <mgrepl> there were changes in libselinux 11:42 <tfirg_> libselinux-2.3-10.fc23.x86_64
Which does not mean this is libselinux bug. Please don't switch bugs in this way without a better look. Thanks.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Whoops I forgot all about this report. This issue should be fixed in https://bugzilla.redhat.com/show_bug.cgi?id=1257157 https://github.com/SELinuxProject/selinux/commit/fec839cf17ba3e9cc9fc5e4382b00c61aee91c80 Now all we need is a update libselinux package in rawhide so that this can be tested.
libselinux-2.4-3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update libselinux'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14873
libselinux-2.4-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.