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.
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.
FS#28378 - Stricter filesystem permissions by default.
Attached to Project:
Pacman
Opened by Jason William Walton (jasonww) - Sunday, 12 February 2012, 15:23 GMT
Last edited by Allan McRae (Allan) - Saturday, 09 February 2013, 04:35 GMT
Opened by Jason William Walton (jasonww) - Sunday, 12 February 2012, 15:23 GMT
Last edited by Allan McRae (Allan) - Saturday, 09 February 2013, 04:35 GMT
|
Detailsmakepkg should check for the option "adjustperms" (or similar) in makepkg.conf and do the following:
If a file or directory is found in either: bin sbin lib usr etc and maybe elsewhere it should change existing permissions of directories that were owned by root:root from 0755 to 0555. files that were owned by root:root 0644 to 0444 files that were owend by root:root 0755 to 0555. In addition, to further restrict access to potentially hijacked services with a mixed (no CAP_DAC_*) capability set files such as kernels, /etc/shadow, /etc/gshadow should default to 0000 as access to these is either irrelevant (the bootloader doesn't care about permission) or are handled by PAM/setuid binaries with elevated permissions anyway. The filesystem package would need some fixing, and so would pacman to reduce the amount of spam due to different permissions in packages and the filesystem. (i.e pacman should not bother warning about 0755 vs 0555 unless its requested.) This has already been done in Fedora (12?) a good while ago and would probably not be much of a big deal. Restricted programs that want to write to the mentioned targets shouldn't exist in the real world, so It's doubtful that implementing this is going to result in any breakage. There might be some other use cases I'm not aware of that would kill this feature request, but I can't really think of anything at the moment. Implementation should be rather simple. |
This task depends upon
Closed by Allan McRae (Allan)
Saturday, 09 February 2013, 04:35 GMT
Reason for closing: Won't implement
Additional comments about closing: https://bugs.archlinux.org/task/28378#co mment105758
Saturday, 09 February 2013, 04:35 GMT
Reason for closing: Won't implement
Additional comments about closing: https://bugs.archlinux.org/task/28378#co mment105758
I am going to suggest an alternative. Allow makepkg to call custom scripts during the "clean-up" phase.
It doesn't need to be flexible, the list as mentioned is just the bare minimum that should be fixable without raising too many questions while at the same time being probably the most important part.
Obviously everything else (permissions on individual files like the kernel) would be up to the maintainers to decide.
I don't really mind if this won't be implemented considering its rather trivial to implement with a simple script especially if you don't have to account for anything but your own use cases.
"Maybe elsewhere" is correct, you can do go far beyond that list but not for every package. You could take away a lot more from UID 0 than that, but then we are getting into complicated territory compared to the presented "no-brainers".
You haven't provided us with a patch here, so we're quite free to object on complexity grounds. I would encourage you to check out the git repo and look at the number of commits we have had to make to fix various shortcomings in binary stripping, man page compression, etc. over the last few years; it is a non-trivial number of commits. Given this past history, understand why are not enthusiastic about this.