On Wed, Jul 19, 2017 at 08:18:55AM +0200, Bernhard Voelker wrote: > On 07/17/2017 11:14 PM, Patrick Steinhardt wrote: > > When setting capabilities, we accept human readable names like for > > example `sys_rawio` or `net_admin`. To do so the translation between the > > capability name and its in-kernel index, we rely on the function > > `capng_name_to_capability`. When the function does not know the named > > capability, it will return an error value and we abort setting the > > capability. > > > > This relies upon the ability of libcap to know all capabilities inside > > of the kernel. But actually, it is possible that new capabilities are > > introduced inside of the Linux kernel which are not recognized yet by > > the library. When dumping these unknown capabilities, libcap will simply > > return a string like "cap_38", that is it will append the capability's > > in-kernel index to the prefix "cap_". This may lead a user to also think > > that "cap_38" may be passed to the switches "--inh-caps" or > > "--ambient-caps", which is unfortunately not the case. > > > > We can do better here by instead accepting strings in the form of > > "cap_N". To do so, we can simply rely on the fact that capability > > indices are steadily increasing and that the highest index known to the > > kernel is stored inside of the kernel's procfs, made readily available > > by our function `real_cap_last_cap()`. So in case libcap does not know a > > capability name, we can simply parse the string and, if it is in the > > correct format, check whether the detected index is between 0 and the > > highest capability index. If so, we can treat it as a valid capability > > string and apply it. > > Thanks - would you mind to also add a sentence to the man page? > > Thanks & have a nice day, > Berny Sure, can do this. I'll send a follow-up patch tomorrow as the patch has already been applied. Patrick
Attachment:
signature.asc
Description: PGP signature
