On 2009-09-15 Stephen Smalley wrote:
> On Tue, 2009-09-15 at 15:20 -0400, Caleb Case wrote:
>> Setfiles now checks the capabilities on the mounted file systems for
>> 'seclabel' (see setfiles/setfiles.c:723:exclude_non_seclabel_mounts)
on
>> newer kernels (>=2.6.30 see setfiles.c:734). However the 'seclabel'
>> feature is not available if selinux is not enabled. The result is
that
>> setfiles silently fails to relabel any filesystems.
>>
>> The patch below removes the check for seclabel if selinux is
disabled.
>>
>> As an alternative maybe seclabel should be available even if selinux
>> is disabled? It seems that whether a fs supports security labels is
>> independent of selinux being enabled.
>
> That would be difficult as the seclabel option is driven by policy,
> not just by the presence/absence of xattr handlers (the issue is
> whether SELinux will honor setxattr operations, which is not the case
> for filesystems using genfscon or context mount options).
>
> So I guess this is the best we can do.
>
What is the best we can do? Should we always attempt to relabel if
selinux is disabled or not?
>> ---
>> policycoreutils/setfiles/setfiles.c | 2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>> diff --git a/policycoreutils/setfiles/setfiles.c
>> b/policycoreutils/setfiles/setfiles.c
>> index 313767a..db2857f 100644
>> --- a/policycoreutils/setfiles/setfiles.c
>> +++ b/policycoreutils/setfiles/setfiles.c
>> @@ -750,6 +750,8 @@ static void exclude_non_seclabel_mounts()
>> /* Check to see if the kernel supports seclabel */
>> if (uname(&uts) == 0 && strverscmp(uts.release, "2.6.30") < 0)
>> return;
>> + if (is_selinux_enabled() <= 0)
>> + return;
>>
>> fp = fopen("/proc/mounts", "r");
>> if (!fp)
--
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.
