Messages in this thread | | | Date | Tue, 10 Nov 2009 09:53:49 -0600 | From | "Serge E. Hallyn" <> | Subject | Re: drop SECURITY_FILE_CAPABILITIES? |
| |
Quoting Steve Grubb (sgrubb@redhat.com): > On Tuesday 10 November 2009 09:07:39 am Serge E. Hallyn wrote: > > I think that's the case most users will care about, whereas the > > remaining differences between CONFIG_SECURITY_FILE_CAPABILITIES=y > > and =n are that with CONFIG_SECURITY_FILE_CAPABILITIES=y : > > > > (1) certain security hooks (task_setscheduler, task_setioprio, and > > task_setnice) do capability set comparisions, > > (2) it is possible to drop capabilities from the bounding set, > > (3) it is possible to set per-task securelevels, > > (4) and it is possible to add any capability to your inheritable > > set if you have CAP_SETPCAP. > > > > Does anyone know of cases where CONFIG_SECURITY_FILE_CAPABILITIES=n > > is still perceived as useful? > > As a library writer, I wished that the kernel behavior was either consistent, > or there is an API that I can use to find out what model we are operating > under. The biggest issue is that for a distribution we know the assumptions > the distribution should be running under. But end users are free to build > their own kernel that has it disabled. This has already lead to dbus not > working at all. > > I also take issue with probing the capability version number returning EINVAL > when its the only way to find out what the preferred version is.
In 2007/2008, KaiGai had floated patches to export capability info over securityfs. If it was something library writers and distros wanted, we could resurrect those patches - and tack on some info about cap-related kernel config.
-serge
| |