Dear Ralph, Thank you very much for the lecture! It seems that the issue may be permissions.     $ sudo /usr/bin/systemd-tmpfiles --create /run/tmpfiles.d/kmod.conf Arch returns:     Detected unsafe path transition / → /dev during canonicalization of /dev.     Detected unsafe path transition / → /dev during canonicalization of /dev.     Detected unsafe path transition / → /dev during canonicalization of /dev.     Detected unsafe path transition / → /dev during canonicalization of /dev.     Detected unsafe path transition / → /dev during canonicalization of /dev.     $ cat /run/tmpfiles.d/kmod.conf     c! /dev/fuse 0600 - - - 10:229     c! /dev/cuse 0600 - - - 10:203     c! /dev/btrfs-control 0600 - - - 10:234     c! /dev/nvram 0600 - - - 10:144     c! /dev/loop-control 0600 - - - 10:237     d /dev/net 0755 - - -     c! /dev/net/tun 0600 - - - 10:200     c! /dev/ppp 0600 - - - 108:0     c! /dev/uinput 0600 - - - 10:223     d /dev/mapper 0755 - - -     c! /dev/mapper/control 0600 - - - 10:236     d /dev/vfio 0755 - - -     c! /dev/vfio/vfio 0600 - - - 10:196     c! /dev/userio 0600 - - - 10:240     c! /dev/vhci 0600 - - - 10:137     c! /dev/uhid 0600 - - - 10:239     c! /dev/vhost-net 0600 - - - 10:238     c! /dev/vhost-vsock 0600 - - - 10:241     d /dev/snd 0755 - - -     c! /dev/snd/timer 0600 - - - 116:33     d /dev/snd 0755 - - -     c! /dev/snd/seq 0600 - - - 116:1 There are more error messages of unsafe path transition if I run $ sudo /usr/bin/systemd-tmpfiles --create without specifying a tmpfile, then all tmpfiles are triggered. After searching on-line, it seemed that similar problems were reported by other users of systemd. The fix is to set owner of / as root.root. I tried the solution and it worked! Running $ sudo /usr/bin/systemd-tmpfiles --create no longers gives me error message! Yours sincerely, Xianwen On 07/09/2019 15.07, Ralph Corderoy wrote:

Dear Xianwen,

...

:: Running post-transaction hooks... ... (5/9) Creating temporary files... error: command failed to execute correctly (6/9) Reloading device manager configuration... Here's the path I trod to investigate this.

$ cd /usr/share/libalpm/hooks $ grep 'Creating temporary files' * systemd-tmpfiles.hook:Description = Creating temporary files... $ $ cat systemd-tmpfiles.hook [Trigger] Type = File Operation = Install Operation = Upgrade Target = usr/lib/tmpfiles.d/*.conf

[Action] Description = Creating temporary files... When = PostTransaction Exec = /usr/share/libalpm/scripts/systemd-hook tmpfiles $ $ file /usr/share/libalpm/scripts/systemd-hook /usr/share/libalpm/scripts/systemd-hook: POSIX shell script, ASCII text executable $ $ grep -1 tmpfiles /usr/share/libalpm/scripts/systemd-hook sysusers) /usr/bin/systemd-sysusers ;; tmpfiles) /usr/bin/systemd-tmpfiles --create ;;

$ $ man systemd-tmpfiles ... DESCRIPTION systemd-tmpfiles creates, deletes, and cleans up volatile and temporary files and directories, based on the configuration file format and location specified in tmpfiles.d(5).

$ man 5 tmpfiles.d ... SYNOPSIS /etc/tmpfiles.d/*.conf /run/tmpfiles.d/*.conf /usr/lib/tmpfiles.d/*.conf

~/.config/user-tmpfiles.d/*.conf $XDG_RUNTIME_DIR/user-tmpfiles.d/*.conf ~/.local/share/user-tmpfiles.d/*.conf ... /usr/share/user-tmpfiles.d/*.conf

So one of the *.conf files in those directory is triggering that error. systemd-tmpfiles(8) says one or more *.conf files can be given after ‘--create’ so I suggest running it on each in turn to see if the error still occurs for one of them. This may required sudo(8).

On 9/8/19 5:20 AM, Ralph Corderoy wrote:

Dear Xianwen,

...

After searching on-line, it seemed that similar problems were reported by other users of systemd. The fix is to set owner of / as root.root. I tried the solution and it worked!

I'm glad you fixed it. / not being root:root is strange. You may wish to

sudo -i pacman -Qqkk

to check for other odd permissions, etc., in case they too cause problems later. Note, it seems normal for some packages to cause grumbles from the above command. If a package is listed, I then do

sudo -i pacman -Qkk atop

to see more detail of the problem. Though unfortunately not enough detail, i.e.

warning: atop: /var/log/atop/dummy_after (Permissions mismatch)

doesn't tell me what they should be. One has to grovel around in the mtree file for that.

$ zcat /var/lib/pacman/local/atop-*/mtree | > grep '^./var/log/atop/dummy_after ' | > fmt ./var/log/atop/dummy_after time=1549485614.0 size=0 md5digest=d41d8cd98f00b204e9800998ecf8427e sha256digest=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 $

This entry doesn't have a ‘mode=...’ stating the desired permissions. mtree(5) doesn't say so, but I think it defaults to 0644 for files based on the other mode-less entries in that mtree file that don't cause pacman to complain.

Not every error means the file on disk must be changed, perhaps it's a packaging problem, but it can be a useful aid.

pacman -S pacutils && paccheck --file-properties -- Eli Schwartz Bug Wrangler and Trusted User

On 9/8/19 7:59 AM, Ralph Corderoy wrote:

$ sudo -i paccheck --file-properties atop atop: '/var/log/atop/dummy_after' permission mismatch (expected 644) atop: '/var/log/atop/dummy_after' modification time mismatch (expected 2019-02-06 20:40:14) atop: '/var/log/atop/dummy_before' permission mismatch (expected 644) atop: '/var/log/atop/dummy_before' modification time mismatch (expected 2019-02-06 20:40:14) $

The modification-time mismatch above suggests the package's mtree needs to allow for the mtime to vary.

Well, it would depend on the file, these ones seem to be logfiles. I wonder why they exist in the package at all, if that is the case?

As an installation ages, it seems the number of disagreements between it and the packages grows. What can be done to try and centrally fix some of them for all installations?

I expect sometimes a package or upstream changed a file's properties in the packaging, but neglected to alter what was already in place on the upgrade to that package version. I'd have thought if research shows it is the package, or upstream, that changed the properties then it's not too late and the package can change to check and fix those on upgrade.

Well, no, pacman will delete the old version and install the new version every time you update or reinstall a package, and in the process it totally ignores the on-disk modification time, permission bits, and previous contents. So it doesn't matter how old your installation is, "disagreements" should remain a constant defined by the package from which it comes. It will be just as much in disagreement the day you install Arch complete with your list of favorite packages, as it will be 25 years later after you've faithfully pacman -Syu'ed once a day/week. The exception is directories, for which pacman explicitly logs a warning that "permissions differ" and expects the user to research why that might be so. Directories are a bit unusual in that multiple packages can own them, after all, so different packages might "legitimately" have different ideas about what permissions a directory should have. These need to be resolved on a higher level than simply "pick the first one pacman extracts". Sometimes, those directories are changed in the one package that owns them. For example, /etc/NetworkManager/system-connections/ used to be readable by any user, which allowed users to see which filenames were available as configured networkmanager connections. Now the package changed to install it as 700, and you cannot use ls in there anymore (but you can still use nmtui/nmcli/nm-applet to view absolutely anything by default). In this case you might well be advised to change the permissions yourself, OTOH maybe you want to leave it as is for personal reasons?

Do the packaging tools provide a means of checking that the proposed mtree differs for existing items to the previous one? That would help packagers realise upstream have made a change.

Well, no. How would you even be able to determine this in the first place? Let's say Joe User's files differ from the package -- mine don't, what do I as a packager do? What about /usr/lib/modules/$(uname -r)/modules.* which are packaged in pristine condition, but then updated by depmod? Those are supposed to not match. What about backup files, which are definitively supposed to not match the packaged version? pacman -Qkk reports these by default: backup file: pacman-git: /etc/makepkg.conf (Modification time mismatch) backup file: pacman-git: /etc/makepkg.conf (Size mismatch) backup file: pacman-git: /etc/pacman.conf (Modification time mismatch) backup file: pacman-git: /etc/pacman.conf (Size mismatch) warning: pacman-git: /usr/share/locale/de/LC_MESSAGES/pacman.mo (UID mismatch) warning: pacman-git: /usr/share/locale/de/LC_MESSAGES/pacman.mo (GID mismatch) warning: pacman-git: /usr/share/locale/de/LC_MESSAGES/pacman.mo (Modification time mismatch) warning: pacman-git: /usr/share/locale/de/LC_MESSAGES/pacman.mo (Size mismatch) yes, I have strange locale files, this is because I tested someone's patch to add localized strings to pacman-conf and that involved cp'ing a .mo file to /usr/share. You'll notice that the locales are a "warning:" (bold yellow) while the backup file is "backup file:" (bold white) paccheck doesn't show backup files, as it has more fine-grained controls and should be toggled via paccheck --file-properties --backup if you really want to check them.

Blindly altering the filesystem to match mtree might be the wrong thing, disguising a real problem. By getting rid of the noise caused by package upgrades, real faults can start to be seen.

Well, sure, that is why it is just a check by default. :) But permissions are "generally" okay. And modification time is nearly meaningless as it doesn't have any effect on the working of the system in nearly all cases. Depending on the files in question and whether they are backup files, size or checksum mismatch is probably an issue (unless they are kernel depmod products, of course). But they can only ever occur when something modifies the file *after* pacman installs it, so there is really no automated way to check for this. -- Eli Schwartz Bug Wrangler and Trusted User

Dear Ralph and Eli, Thank you. As Ralph suspected, there are quite many files on my system that had wrong permissions or GID's. Is there a way to automatically correct all the permissions and GID's? Yours sincerely, Xianwen On 08/09/2019 11.28, Eli Schwartz via arch-general wrote:

On 9/8/19 5:20 AM, Ralph Corderoy wrote:

...

Dear Xianwen,

...

After searching on-line, it seemed that similar problems were reported by other users of systemd. The fix is to set owner of / as root.root. I tried the solution and it worked! I'm glad you fixed it. / not being root:root is strange. You may wish to

sudo -i pacman -Qqkk

to check for other odd permissions, etc., in case they too cause problems later. Note, it seems normal for some packages to cause grumbles from the above command. If a package is listed, I then do

sudo -i pacman -Qkk atop

to see more detail of the problem. Though unfortunately not enough detail, i.e.

warning: atop: /var/log/atop/dummy_after (Permissions mismatch)

doesn't tell me what they should be. One has to grovel around in the mtree file for that.

$ zcat /var/lib/pacman/local/atop-*/mtree | > grep '^./var/log/atop/dummy_after ' | > fmt ./var/log/atop/dummy_after time=1549485614.0 size=0 md5digest=d41d8cd98f00b204e9800998ecf8427e sha256digest=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 $

This entry doesn't have a ‘mode=...’ stating the desired permissions. mtree(5) doesn't say so, but I think it defaults to 0644 for files based on the other mode-less entries in that mtree file that don't cause pacman to complain.

Not every error means the file on disk must be changed, perhaps it's a packaging problem, but it can be a useful aid. pacman -S pacutils && paccheck --file-properties

Dear Ralph, Great! Thank you very much for the tips! Yours sincerely, Xianwen On 08/09/2019 15.11, Ralph Corderoy wrote:

Dear Xianwen,

...

there are quite many files on my system that had wrong permissions or GID's. Perhaps there's been an errant recursive chmod or chgrp in the past by root.

...

Is there a way to automatically correct all the permissions and GID's? Others like Eli might know an mtree-specific way, but if there's a common feature, like lots of files under /usr/bin that are group xianwen instead of root, then find(1) could be used to first list what it would change, allowing the list to be checked by eye, and then correct. Something like

find -xdev /usr/bin -group xianwen -ls find -xdev /usr/bin -group xianwen -exec chgrp root {} +

https://mywiki.wooledge.org/UsingFind might help if you're not familiar with find(1). It has -user and -perm too.

Or you could try and use the output of paccheck(1) to produce a script to execute, again after checking it by eye.

sudo -i paccheck --quiet --file-properties | awk ' / permission mismatch / { print "chmod 0" substr($6, 1, length($6)-1), $2 } '

Dear Eli, Thank you! Is there a way to ask paccheck to list only files that need to be fixed? For example, if I run     sudo paccheck --file-properties --quiet I get list of files with package information and error information, such as     screen: '/usr/lib/tmpfiles.d/screen.conf' permission mismatch (expected 644) Or maybe I need to write a regular expression to extract file name and path from such an output myself? Yours sincerely, Xianwen On 08/09/2019 19.14, Eli Schwartz via arch-general wrote:

On 9/8/19 8:21 AM, Xianwen Chen (陈贤文) via arch-general wrote:

...

Dear Ralph and Eli,

Thank you.

As Ralph suspected, there are quite many files on my system that had wrong permissions or GID's.

Is there a way to automatically correct all the permissions and GID's? Once more from the pacutils package, comes the "pacrepairfile" command. Given a list of files and the (separate, additive) arguments --uid --gid --mode --mtime you can reset the file to what its mtree data specified. If the file size/contents differ, you will have to do a bit of manual work yourself, or reinstall the package.

Dear Eli, Thank you. I wrote a regulation expression, which extracts file name and path from the output of paccheck: $ sudo paccheck --file-properties --quiet | grep -Po "(?<=\').*(?=\')" | sudo pacrepairfile --uid --gid --mode --mtime However, somehow pacrepairfile was not working. For example, $ sudo pacrepairfile --uid --gid --mode --mtime /usr/lib/tmpfiles.d/colord.conf outputs     /usr/lib/tmpfiles.d/colord.conf: set uid to 0     /usr/lib/tmpfiles.d/colord.conf: set gid to 0     warning: /usr/lib/tmpfiles.d/colord.conf: unable to set permissions (Operation not supported)     /usr/lib/tmpfiles.d/colord.conf: set modification time to 1555511829 What happened with pacrepairfile? Yours sincerely, Xianwen On 08/09/2019 22.53, Eli Schwartz via arch-general wrote:

On 9/8/19 4:40 PM, Xianwen Chen (陈贤文) via arch-general wrote:

...

Dear Eli,

Thank you!

Is there a way to ask paccheck to list only files that need to be fixed?

For example, if I run

    sudo paccheck --file-properties --quiet

I get list of files with package information and error information, such as

    screen: '/usr/lib/tmpfiles.d/screen.conf' permission mismatch (expected 644)

Or maybe I need to write a regular expression to extract file name and path from such an output myself? No, paccheck does not have an option to do this. You could try submitting a feature request for it. :)

You can extract everything between the '' though, which I think should handle any filenames since packaged filenames can contain spaces or single quotes but not newlines, and the paccheck output doesn't contain any more single quotes after the quoted filename.

Dear Eli, Thank you! Question regarding status of the bug has been filed! Yours sincerely, Xianwen On 09/09/2019 00.47, Eli Schwartz via arch-general wrote:

On 9/8/19 6:27 PM, Xianwen Chen (陈贤文) via arch-general wrote:

...

For example,

$ sudo pacrepairfile --uid --gid --mode --mtime /usr/lib/tmpfiles.d/colord.conf

outputs

    /usr/lib/tmpfiles.d/colord.conf: set uid to 0     /usr/lib/tmpfiles.d/colord.conf: set gid to 0     warning: /usr/lib/tmpfiles.d/colord.conf: unable to set permissions (Operation not supported)     /usr/lib/tmpfiles.d/colord.conf: set modification time to 1555511829

What happened with pacrepairfile? Ah, now I remember that https://github.com/andrewgregory/pacutils/issues/32 is a thing. :)

The --mode option has some issues. Perhaps try asking for a status update there?