[Rpm-maint] [rpm-software-management/rpm] rpm --setcaps sets empty security.capability when there is no caps (#585)

[pavlinamv]

It is a very good point. 

Empty capabilities ('') and no capabilities are different. Because (from SETCAP(8) man page):
"setting an empty capability set is not the same as removing it. An empty set can be used to guarantee a file is not executed with privilege inspite of the fact that the prevailing ambient+inheritable sets would otherwise bestow capabilities on executed binaries"

If %|FILECAPS? is false for a given package then --setcaps should set no caps. This is a bug in the current --setcap implementation and it must be corrected.

If %|FILECAPS? is true for a given package then %{FILECAPS} contains textual representation of file capabilities. In such a case files with no capabilities and files with empty capabilities satisfies %{FILECAPS}=''. So from the value %{FILECAPS}='' it is not clear whether a file has no or empty capabilities. I checked several packages (iputils, gnome-keyring, httpd, mtr). After package installation the files with %{FILECAPS}='' usually have no capabilities. But because 
1) empty capabilities are more strict then no capabilities and 
2) %{FILECAPS} can be used as a querytag to print out capabilities of a file
I think the correct solution is: if  %{FILECAPS} = '' then capabilities should be set empty. In case of no capabilities %{FILECAPS} must contain a different value.  And with respect to this correct --setcups. 

There is another problem:
rpm -V does not differ between no capabilities and empty capabilities now. E.g. if a file /usr/bin/mc has empty or no capabilities rpm -V verifies both as correct. It should be corrected.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/585#issuecomment-435394654
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20181102/b64657f7/attachment.html>