[solved] Causes for permission missmatch on installed files

lamarpavel · 2018-05-18 06:24:11

I did a pacman -Qkk today and found a few files reporting a :warning: [...] (Permissions mismatch). For some of them, this seemed okay-ish, like /boot/grub/grub.cfg, which has 0600 and is owned root:root. It's not impossible that I changed that myself, though I can't remember doing so. Reading pacmans manpage, I could not find out how to display the supposed permissions, though. Is there a utility for displaying the difference in supposed and actual permission?

Moving on, there was one file that actually worried me and that was /usr/lib/libkeyutils.so.1.6, which had a permission of 777 (root:root). No chance that I did that knowingly. After re-installing keyutils, the permissions are 755 (root:root).
What could be the cause of this? Should I be worried? I figure there is not much of a chance to find out who or what modified that file?

Last edited by lamarpavel (2018-05-18 19:25:03)

mpan · 2018-05-18 08:16:00

Many files are generated and therefore may be overwriten: possibly with different permissions. /boot/grub/grub.cfg is one of them, generated usually by grub-mkconfig during one of the standard installation steps.

To check expected permissions:

$ tar -tJvf "/var/cache/pacman/pkg/$PKG_FILE"  | grep -F "$FILENAME"

The $FILENAME should not contain the leading slash. For example:

 $ tar -tJvf /var/cache/pacman/pkg/grub-2\:2.02-5-x86_64.pkg.tar.xz  | grep -F boot/grub/grub.cfg
-rw-r--r-- root/root      4087 2018-03-14 21:56 boot/grub/grub.cfg

The case of /usr/lib/libkeyutils.so.1.6 is strange indeed. It should be 755. I have no idea, why it is 777 on your system — except the usual suspects: dirty hacks to make something work few years earlier and forgeting about it, AUR packages etc.

Last edited by mpan (2018-05-18 08:16:19)

lamarpavel · 2018-05-18 09:59:06

Thank you, that answer was very helpful. Based on your hint I'm now going through all my archived packages to see if any of them modify libkeyutils.so.1.6:

for F in *.tar.xz; do ret="$(tar -tJvf "$F" 2>/dev/null | grep -F libkeyutils.so.1.6)" ; if [ -n "$ret" ]; then echo "$F\n$ret"; fi; done

That's going to take a while, but maybe something will turn up in some old version of a package or in an aur package.

lamarpavel · 2018-05-18 19:24:33

Well, no luck finding a culprit in either the official or the aur packages that I have archived.
At least it seems the file wasn't altered (permanently) since then pacman -Qkk would have reported a checksum missmatch as well as a permission missmatch. (right?) Still, I feel uneasy about this.

Anyway, I'll mark this thread solved. Thanks for your help, mpan.

mpan · 2018-05-19 19:55:18

For the future: the code from your post can be replaced with:

pacman -Fs libkeyutils.so.1.6

Note: you need to synchronize files database earlier, using sudo pacman -Fy — this is being done separately from the sync database! Alternatively you may use:

pkgfile libkeyutils.so.1.6

lamarpavel · 2018-05-20 10:01:28

Good to know. But that would only search through the database in its current form, doesn't it? If I want to search through old packages that might have changed my files some time in the past, or packages built from the AUR, I would still need to search through the pkg.tar.xz archives.

mpan · 2018-05-20 18:26:47

Yes, you are right on that.

Arch Linux

#1 2018-05-18 06:24:11

[solved] Causes for permission missmatch on installed files

#2 2018-05-18 08:16:00

Re: [solved] Causes for permission missmatch on installed files

#3 2018-05-18 09:59:06

Re: [solved] Causes for permission missmatch on installed files

#4 2018-05-18 19:24:33

Re: [solved] Causes for permission missmatch on installed files

#5 2018-05-19 19:55:18

Re: [solved] Causes for permission missmatch on installed files

#6 2018-05-20 10:01:28

Re: [solved] Causes for permission missmatch on installed files

#7 2018-05-20 18:26:47

Re: [solved] Causes for permission missmatch on installed files

Board footer