Stephen Smalley wrote:
...
> FWIW, there is a subtle difference here:
> - chcon can in fact work on a SELinux-disabled kernel, as you can still
> set the security.* extended attributes as long as the filesystem
> provides handlers for the security.* namespace.
> - runcon cannot work without a SELinux-enabled kernel, as only a
> SELinux-enabled kernel allows you to set the security context of a
> running process.
>
> So by preventing chcon from running in the SELinux-disabled case, you
> are imposing a restriction above and beyond what is strictly required.
> The user can of course still use setfattr -n security.selinux -v
> <context> <path> to set a SELinux security context on a file when
> SELinux is disabled, or can run the setfiles program to set SELinux
> security contexts on an entire file tree even when SELinux is disabled.
...
>> diff --git a/src/chcon.c b/src/chcon.c
>> index fbfdb4d..c0da694 100644
>> --- a/src/chcon.c
>> +++ b/src/chcon.c
>> @@ -519,6 +519,10 @@ main (int argc, char **argv)
>> usage (EXIT_FAILURE);
>> }
>>
>> + if (is_selinux_enabled () != 1)
>> + error (EXIT_FAILURE, 0,
>> + _("%s may be used only on a SELinux kernel"), program_name);
>> +
Thanks for the tip.
I'll revert that part of the patch.
I'll address the original problem by adding
getfilecon and lgetfilecon wrappers that
map those unusual cases (10,"unlabeled" and 0,NULL)
to a return value of -1 with errno == ENOTSUPP.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
