Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#55762 - [libalpm] hooks should check for permission

Attached to Project: Pacman
Opened by Erich Eckner (deepthought) - Wednesday, 27 September 2017, 04:35 GMT
Last edited by Allan McRae (Allan) - Tuesday, 06 February 2018, 01:34 GMT
Task Type Feature Request
Category Backend/Core
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 5.0.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Summary and Info:

libalpm hooks should check for write permission before pacman is allowed to upgrade packages (like it is done with write permission / disk space for installing/upgrading packages).
Example:
I have /boot mounted ro and upgrading a package which triggers 90-linux.hook will let the hook fail, but not the package installation.
In contrast, installing/upgrading 'linux' will lead to a 'permission denied' error and not upgrade any packages.
This task depends upon

Closed by  Allan McRae (Allan)
Tuesday, 06 February 2018, 01:34 GMT
Reason for closing:  Not a bug
Additional comments about closing:  pre-transaction hooks can achieve this
Comment by Eli Schwartz (eschwartz) - Wednesday, 27 September 2017, 05:01 GMT
And how would the hook know which directories must be writable? It's easy to check the package filelist, less easy to check the arbitrarily powerful results of an unrestricted subprocess.

In theory, we could add a configuration key to specify the path(s) that must be writable. But that assumes the hook author knows them ahead of time, which is by no means guaranteed.
Comment by Erich Eckner (deepthought) - Wednesday, 27 September 2017, 05:15 GMT
yes, a key in the hook would be my suggestion, too. I had '90-linux.hook' in mind - there it's easy to figure out which path must be writable.
Comment by Allan McRae (Allan) - Wednesday, 27 September 2017, 05:42 GMT
We probably should do the filesystem mountpoint check before we run the pre-transaction hooks. Not a full solution, but I'd guess would catch most cases.
Comment by Andrew Gregory (andrewgregory) - Wednesday, 27 September 2017, 11:29 GMT
You mean the diskspace check? Pre-transaction hooks run immediately after that already. 90-linux.hook is a post-transaction hook; how is pacman supposed to check permissions for post-transaction hooks which can be altered during the transaction?
Comment by Allan McRae (Allan) - Wednesday, 27 September 2017, 11:33 GMT
I was being dumb... of course the linux kernel is not the only package to trigger that hook.

I'm thinking this is a "won't fix - system admin error" bug.
Comment by Erich Eckner (deepthought) - Wednesday, 27 September 2017, 11:36 GMT
I don't understand, why 90-linux.hook can not check write permission of the mount point before the transaction, nor why this would not solve the issue and similar ones.
Comment by Andrew Gregory (andrewgregory) - Wednesday, 27 September 2017, 11:40 GMT
Because the transaction can alter the post-transaction hooks; so pacman can't know before the transaction what post-transaction hooks will run. You are free to create a pre-transaction hook to check the mountpoint yourself though.
Comment by Erich Eckner (deepthought) - Wednesday, 27 September 2017, 11:42 GMT
Ah, right, my bad.
Comment by Erich Eckner (deepthought) - Wednesday, 27 September 2017, 11:59 GMT
So this is rather an issue of the linux package, which does not provide a hook coming with 90-linux.hook, which would check if 90-linux.hook's actions have the necessary (write) permissions?
Comment by Andrew Gregory (andrewgregory) - Wednesday, 27 September 2017, 12:40 GMT
It's an issue of you mounting a directory read-only and not taking the necessary precautions to remount it rw before trying to update it. You're welcome to try to convince the packager to include such a hook, though.

Loading...