[arch-general] [ Pacman -Syu ] Creating temporary files..., error: command failed to execute correctly

[Eli Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20190908/f4d5a427/attachment.sig>