Re: capget() overflows buffers.

From: Chris Wright
Date: Fri May 23 2008 - 21:28:37 EST

* Andrew G. Morgan (morgan@xxxxxxxxxx) 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

> | 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).

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at