Re: drop SECURITY_FILE_CAPABILITIES?

[Steve Grubb <sgrubb@redhat.com>]

On Tuesday 10 November 2009 10:53:49 am Serge E. Hallyn wrote:
> > > 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.

Unfortunately, I would have to support the kernels from 2.6.26->2.6.32 which 
presumably don't have this facility. So, I'm kind of stuck. I think in a 
previous discussion you mentioned that I could call getcap or 
prctl(PR_CAPBSET_READ) and check for CAP_SETPCAP. I think I have to go that 
direction for backwards compatibility.

But back to detecting the capability version number...if I pass 0 as the 
version in the header, why can't the kernel just say oh you want the preferred 
version number, stuff it in the header, and return the syscall with success and 
not EINVAL?

Another irritation...if I want to clear the bounding set, I have to make a for 
loop and call prctl 34 times (once for each bit). I'd rather see a v4 
capability that takes the bounding set as part of the same syscall. Maybe all 
3 of these could be fixed in the same OS release so that changing to v4 also 
signifies the other behavior changes.

-Steve