On Tue, Apr 1, 2014 at 2:36 PM, Patrick Farrell <paf(a)cray.com> wrote:
Thank you for the pointer. I believe we were disabling it by changing
/etc/sysconfig/selinux - Just setting it to disabled instead of permissive
or enforcing. That takes effect after a reboot. (On these systems,
sestatus does show "disabled", but of course, the selinux inode cache is
Presumably, that's a runtime disable, as you described. Thank you for
pointing out the boot parameter option.
Sure thing; yes, that seems to be a runtime disable that happens during the
base policy load. For completeness, selinux_init_load_policy() in
in (currently) line 329 calls selinux_getenforcemode() to read the
/etc/selinux/config file, and writes to the /selinux/disable file if
I suspect the cache is not destroyed intentionally, as having to check if
the cache exists would require some locking to be added on a hot VFS path.
We're probably still going to disable it in our kernel builds at Cray - we
build custom kernels even aside from Lustre's requirement for them - but
that's likely to be useful for others in the community, and good to know
- Patrick Farrell
On 04/01/2014 03:59 PM, Nikitas Angelinas wrote:
Patrick, could you please check how you are disabling SELinux?
On my SL 6.2 (with a 2.6.32-220.23.1.el6.x86_64) test system, adding a
boot parameter of selinux=0 avoids creating the selinux_inode_security
cache, and that is what should happen by looking at the code.
The only other way that I am aware of for disabling SELinux (i.e.
completely, not just turning it into permissive mode) is to write to
/selinux/disable, likely from within initramfs, if
CONFIG_SECURITY_SELINUX_DISABLE is set and selinuxfs is mounted.
The former case should print a "SELinux: Disabled at boot." string on
the kernel ring buffer, and the latter should print a "SELinux: Disabled
at runtime." string. In the latter case the selinux_inode_security cache
does not get destroyed when SELinux is disabled, and a new object gets
allocated from selinux_inode_security for every new inode that gets created.
In case you are not aware, you can check the status of SELinux using
sestatus(8) from the policycoreutils package.
On Mon, Mar 31, 2014 at 7:33 AM, Patrick Farrell <paf(a)cray.com> wrote:
> We at Cray recently noticed that on CentOS 6.4/5 servers even with
> SELinux disabled there is still a noticeable amount of memory in use:
> cat /proc/slabinfo | grep selinux
> selinux_inode_security 7578 7579 72 53 1 : tunables 120
> 60 0 : slabdata 143 143 0
> That's from an idle server, and it's not much usage (7579 objects, 72
> bytes per object, ~ 0.5 MB of memory), but on an active server, there can
> be millions of objects, leading to a few hundred MB of memory usage.
> As far as I can tell, disabling selinux is required for Lustre servers to
> function. When the kernel is built with SELinux disabled in the .config,
> this memory usage goes away.
> I'd like to propose changing the Lustre provided RHEL kernel config file
> to not build SELINUX in to the kernel.
> This won't affect clients unless they're running the patched kernel -
> only the patched Lustre server kernels are changed by this, and as far as I
> know, servers always have SELinux disabled.
> I wanted to float this to a broad audience and get any objections before
> creating an LU and pushing a patch to Gerrit. Does anyone have a reason
> not to do this?
> - Patrick Farrell
> Patch, in essence:
> --- kernel-2.6.32-2.6-rhel6-x86_64.config
> +++ kernel-2.6.32-2.6-rhel6-x86_64.config
> @@ -4411,15 +4411,7 @@
> # CONFIG_SECURITY_ROOTPLUG is not set
> -# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
> +# CONFIG_SECURITY_SELINUX is not set
> # CONFIG_SECURITY_SMACK is not set
> # CONFIG_SECURITY_TOMOYO is not set
> HPDD-discuss mailing list