Re: drop SECURITY_FILE_CAPABILITIES?

[Steve Grubb <sgrubb@redhat.com>]

On Wednesday 18 November 2009 11:40:13 am Andrew G. Morgan wrote:
> >> 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?
> 
> This is so a library can understand that it doesn't understand the
> current ABI.

If user space is passing a NULL for the cap_user_data_t argument, user space 
has a pretty good idea that its not expecting actual capabilities to be filled 
in. My basic point is that there is no way to "correctly" use the capabilities 
API to determine what the preferred version is.


> For example, consider the case of some kernel of the
> future with a different ABI meeting an old library.

Right. Either user space checks version numbers to verify it knows what its 
doing and errors out, or it blindly tries to set capabilities and gets an 
error. Either way, if user space is *really* using the API to do work, it 
won't be passing NULL as the user data argument.

Maybe if version is set to 0 and NULL is being passed for arg 2 to getcap, 
that would be the secret handshake that lets the kernel know all I want is the 
preferred version number and nothing else since there is no data structure to 
fill in.


> The intention is for it to fail safe and not blunder on doing
> "security" related operations with an imperfect idea of the current
> kernel interface.
> 
> This is how libcap figures out it can work with the hosting kernel:

capget(0x20080522, 0, NULL)             = -1 EFAULT (Bad address)

Still an error.

-Steve