Restorecon Equivalent for Unix Permissions

SE Linux has a utility named restorecon to set (or reset) the security context. This is useful for many reasons, corrupted filesystems, users removing files or changing the context in inappropriate ways, and for re-creating files from tar files or backup programs that don’t restore SE Linux contexts. It can also be used to report the files that have different contexts to that which would be set by restorecon to verify the contexts of files.

Restorecon determines the context from two sources of data, one is the policy that came with the system (including any policy modules from other sources which were loaded) and the other is the local file contexts that were created by semanage.

It’s a pity that there doesn’t seem to be an equivalent program for Unix permissions. rpm has a -V option to verify the files from a package and dpkg doesn’t seem to have an option to perform a similar operation (/var/lib/dpkg/info/* doesn’t seem to have the necessary data). But even on an RPM based system this isn’t possible because there is no way to add local files into the list.

I would like to be able to specify that an RPM system should have root:root as the owner and permission mode 0755 for all files matching /usr/local/bin/* and use a single command to check the RPM database as well as this extra data for the permissions of all files.

Does anyone know of any work in this area?

I’m going to file Debian and Fedora bug reports about this, but I would appreciate any comments first.


Here is an example of how this feature works in rpm:
# rpm -Vv nash
…….. /sbin/nash
…….. d /usr/share/man/man8/nash.8.gz
# chmod 700 /sbin/nash
# rpm -Vv nash
.M…… /sbin/nash
…….. d /usr/share/man/man8/nash.8.gz

The “M” character indicates that the permission mode of the file does not match the RPM. There is no way to automatically correct it (AFAIK) but at least we know that something changed. With Debian AFAIK it’s only possible to verify file checksums not the permission.

10 comments to Restorecon Equivalent for Unix Permissions

  • debsums does something similar to rpm -V, provided the package provides md5sums.

  • Well you’ll need to package everything under /usr/local/bin/* into rpm format. There isn’t another way with rpm to the best of my knowledge.

    This quick hack was knocked up in about 20 minutes (to perfect it):

    If my webhost wasn’t down right now, I’d simply upload it to my website.

    So download that script, save it as restoreperms and do this to run “restorecon”:
    restoreperms -p $packagename -f

    Russel, let me know if you like it. I’ll add more features in the morning after some sleep

  • Vaclav Ovsik

    There is an interesting command mtree on *BSD systems.
    I’m Debianist, but I know this from some FreeBSD running at my company.


    mtree is packaged in freebsd5-buildutils and its called freebsd-mtree.

    Maybe, there is something more appropriate…

  • Vaclav Ovsik

    Grrr freebsd-mtree from freebsd5-buildutils is nonfunctional.

  • etbe

    Andrew: I’ve updated the post, debsums doesn’t address this problem at all. In a quick test running chmod on a file was not detected by it.

    Jeff: Great work! Now all we need is to have it consult another data source for files that aren’t owned by RPM packages and we’ll have a Unix permissions equivalent to restorecon.

    Vaclav: That seems to be more like Tripwire than what I’m interested in. It starts with copying the permissions from an installed system rather than using installation binaries to get the permissions – which makes sense as BSD doesn’t have binary packages.

  • Vaclav Ovsik

    etbe: I think you are not right. BSD systems have binary packages. For example:
    If you look inside some package, you will see some topmost files and +MTREE_DIRS in between. Mtree is build into *BSD packaging system I think. And maybe Debian can add something similar aside debsums for this into dpkg. Something like mtree file can be generated in package building phase I think.

  • Name (required)

    Isnt this what ids like aide, tripwire, samhain, etc, etc are for?

  • etbe

    Vaclav: It sounds like BSD is doing some good things in this regard, so all we need to do is to update dpkg to allow the same.

    Name: An IDS is not a tool for recovering from sys-admin mistakes, and Tripwire etc are not integrated with the packaging system (the primary authoritative source of data about such things).

    Gurkan: your comment is similar to Steve Kemp’s suggestion in his blog. Still not part of the system.

  • Russell, here is a finished version for you:

    I thought about setting this up to work with normal (read non-rpm managed) files and decided against it. Just create a quick hacky spec of everything in /usr/local/bin/* and then you can use this. If not, maybe it will help you out someday? Thanks for the idea though, it was all yours.

    It now shows which files have changed and the permissions they are currently vs the ones they should be. If you have an rpm distro installed, check it out.