lkml.org 
[lkml]   [2009]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: drop SECURITY_FILE_CAPABILITIES?
Date
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


\
 
 \ /
  Last update: 2009-11-18 18:53    [W:0.058 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site