`capng_apply` applies ambient caps too early? about libcap-ng

[snarkmaster]

Note that this is a bug that may not be obvious to users because both of the capng_apply calls return 0.

[snarkmaster]

Unrelatedly, this code here seems to skip the CapAmb: line that the sscanf would attempt to parse?

libcap-ng/src/cap-ng.c

Line 408 in e255e07

if (strncmp(buf, "CapA", 4))

I.e. I'm not sure whether this get_ambient_set works correctly either.

[stevegrubb]

Strange. In my testing I was using capng_print_caps_numeric() which hides what the system really thinks. Fixed now.
About the sscanf code, if strcmp() == 1, then we want to read the next line. Its only when its 0 that we want to read it.

[snarkmaster]

Thanks for putting up a fix! I'll test perhaps Monday.

testing using the internal state of capng

That's actually also the topic of my next bug report.

You'll notice that in my repro program I cross-check the result of capng_apply against procfs. I think it would be good if libcap-ng did that internally, feel free to use my proc-parsing code -- I can put up a cleaned-up version (it'll be on github soon, but you can have it even sooner :)

strncmp

So strncmp will return 0 if the two strings are equal, which means that you will continue; instead of going on to do sscanf. Am I reading this wrong?

This would also be improved if you adopt my procfs parser.

[stevegrubb]

So strncmp will return 0 if the two strings are equal, which means that you will continue; instead of going on to do sscanf.
If strncmp returns a 0, strings match and the "if" fails so we run sscanf. If they mismatch, the "if" is true and we take the continue.

[snarkmaster]

Sorry, you're right about the strncmp control flow, and I was having a brain glitch. My apologies for taking up your time with this.

[snarkmaster]

I can confirm that b6ff250 fixes the reported issue. However, as per my comment on the subsequent commit 6a24a9c, that one breaks the mitigation that one would need to use before the fix.

I.e. right now I just literally do capng_apply(CAPNG_SELECT_ALL); twice in a row.

After 6a24a9c, the second capng_apply fails, which to me seems weird.

I guess I could handle the new world by not checking errors on the second capng_apply, but that feels dirty, and besides, the semantics of "a no-op apply succeeds" seems more right than a "no-op apply fails". I thought the philosophy of libcap-ng was to free the end user from managing caps state. Avoiding the "no-op" error requires actively checking whether or not you're making a change before you call capng_apply, which IMO makes the API harder to use.