FS#58701 - Pacman fails to uninstall symlink to the file/directory on the read-only file system

Attached to Project: Pacman
Opened by Aliaksandr Stelmachonak (ava1ar) - Wednesday, 23 May 2018, 03:05 GMT
Last edited by Eli Schwartz (eschwartz) - Wednesday, 23 May 2018, 03:12 GMT
Task Type Bug Report
Category Backend/Core
Status Unconfirmed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 5.0.1
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 2
Private No

Details

Description: If installed package contains symlink to the file/directory located on the read-only filesystem (mount as ro), pacman fails to remove the symlink during uninstall. Event worse, package considered as deleted after this failure, but all package files are still present in the filesystem and become unattended.

Additional info:
Pacman v5.0.2 - libalpm v10.0.2

Steps to reproduce:
1. Mount (bind mount) some filesystem in read-only mode - i.e.:
$ sudo mount -o bind,ro / /mnt
2. Create and install simple PKGBUILD, which creates symlink to the file/dir under /mnt, i.e. pacman-test from here: https://pastebin.com/rYspdLYN (I also attached a copy)
3. Install built package
4. Try to uninstall built package:
$ sudo pacman -R pacman-test
You will get the following:
error: cannot remove file '/usr2': Read-only file system

pacman-test will be removed from pacman's db, so package won't be considered installed anymore, but /usr2 symlink will still be in the filesystem. All other package files will also remain not removed.
This task depends upon

Comment by Aliaksandr Stelmachonak (ava1ar) - Wednesday, 23 May 2018, 03:06 GMT
This is test PKGBUILD. Don't forget to do "sudo mount -o bind,ro / /mnt" before installing to reproduce the issue.
   PKGBUILD (0.2 KiB)
Comment by Allan McRae (Allan) - Wednesday, 23 May 2018, 06:06 GMT
Interesting bug. So the package file is not actually on the RO filesystem... seems we might need a lstat instead of stat?
Comment by Aliaksandr Stelmachonak (ava1ar) - Wednesday, 23 May 2018, 06:08 GMT
I think stat -> lstat should fix it. No sure, if there are any possibilities for regression somewhere after the change?
Comment by Andrew Gregory (andrewgregory) - Wednesday, 23 May 2018, 06:39 GMT
It's not stat, it's access, which does not symlink-capable version.
Comment by Allan McRae (Allan) - Wednesday, 23 May 2018, 14:11 GMT
I think faccessat() with the AT_SYMLINK_NOFOLLOW flag would do it. But I am not sure about portability.
Comment by Andrew Gregory (andrewgregory) - Wednesday, 23 May 2018, 14:24 GMT
Unfortunately, that's a glibc extension. It causes glibc to do the check itself using fstatat, which is probably what we should do.
Comment by Allan McRae (Allan) - Wednesday, 23 May 2018, 14:34 GMT
This also highlights other issues with removal. We should probably do file access checks before any removal (although there is race conditions here), and then not bail half way though a package removal to avoid half uninstalled packages.
Comment by Aliaksandr Stelmachonak (ava1ar) - Saturday, 17 November 2018, 05:10 GMT
No plans to fix this?
Comment by Andrew Gregory (andrewgregory) - Saturday, 17 November 2018, 05:17 GMT
Patches welcome!
Comment by Aliaksandr Stelmachonak (ava1ar) - Saturday, 17 November 2018, 05:21 GMT
I am not that good at C/C++, but will see what can I do there :)
Comment by Christian Heusel (gromit) - Saturday, 02 September 2023, 10:43 GMT
If you still experience this bug feel free to reopen it in the pacman project in Gitlab: https://gitlab.archlinux.org/pacman/pacman

But I think the very recently opened https://gitlab.archlinux.org/pacman/pacman/-/issues/49 describes the same issue.

Loading...