Using setcap to give additional permissions to a binary should write the new permission somewhere, on storage or in memory, where is it stored ?

Using lsof as is doesn't work because the process disappear too quickly.

  • Use another process. Make a copy of /usr/bin/sleep and give the capabilities to this copy. – Hauke Laging Aug 26 '17 at 16:57

Extended permissions such as access control lists set by setfacl and capability flags set by setcap are stored in the same place as traditional permissions and set[ug]id flags set by chmod: in the file's inode.

(They may actually be stored in a separate block on the disk, because an inode has a fixed size which has room for the traditional permission bits but not for the potentially unbounded extended permissions. But that only matters in rare cases, such as having to care that setcap could run out of disk space. But even chmod could run out of disk space on a system that uses deduplication!)

GNU ls doesn't display a file's setcap attributes. You can display them with getcap. You can list all the extended attributes with getfattr -d -m -; the setcap attribute is called security.capability and it is encoded in a binary format which getcap decodes for you.


setcap sets file capabilities which are stored in filesystem extended attribute. These are explained in man 7 capabilities:

The file capability sets are stored in an extended attribute (see setxattr(2)) named security.capability.

You can inspect the capabilities of a running process by examining CapInh/CapPrm/CapEff fields in /proc/PID/status. See my answer to "How to set capabilities with setcap command?" for explanation on how the capabilities are applied to process at exec.

  • capsh --decode= could come handy to get human readable data. – Zulgrib Aug 26 '17 at 21:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.