Messages in this thread | | | Date | Fri, 23 May 2008 18:09:23 -0700 | From | Chris Wright <> | Subject | Re: capget() overflows buffers. |
| |
* Andrew G. Morgan (morgan@kernel.org) wrote: > Chris Wright wrote: > | I'm sure you're painfully aware, but this will need some change > | to libcap as well (to let it handle 64bit caps again). > > Not really. > > libcap2 (the one with 64-bit capability support) continues to work fine > (it ships with its own copy of a compatible linux/capability.h, and when > I update that, I'll make the corresponding change) but the effect should > be transparent to its users:
Doh, I missed the leading portion of the pathname (cscope -p3 didn't show anything more than include/sys/capability.h), thanks.
> | That's what I meant earlier by "And use another mechanism to > | signal the availability of 64bit caps." > > There is and has always been a method: > > ~ head.version = 0; > ~ getcap(&head, NULL); > ~ switch (head.version) { > ~ case _LINUX_...: > ~ ... > ~ break; > ~ case _,,,,: > ~ etc... > ~ break; > ~ default: > ~ abort("no idea what to do"); > ~ }
Hmm, it would be kind of nice to have a formalized way get the size, perhaps it would help with KaiGai's request for caps printed out. Something that tells us either the number of u32s, or the max bit supported?
> | All looks good. I think we need to issue some warnings, because > | at least Fedora 9 and openSUSE 11 are/will be 2.6.25 based. > > Do any of the above answers help? (FWIW I attached the patch to the > redhat bug.)
Yes, thanks. But I still think we need to print a warning (unfortunately we can't distinguish libcap from non-libcap app), because apps that aren't using libcap should really be updated (either pull new update from vendor or recompiled by end user).
thanks, -chris
| |