warning: directory permissions differ on /usr/share/polkit-1/rules.d/ filesystem: 750 package: 755 (5/6) upgrading polkit [########################################################################] 100%warning: directory permissions differ on /usr/share/polkit-1/rules.d/ filesystem: 750 package: 755 What are correct permissions for these directories and has the upgrade corrected permissions that neede correction? -- Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940.
On Thu, 2024-01-18 at 10:32 -0500, Jude DaShiell wrote:
What are correct permissions for these directories and has the upgrade corrected permissions that neede correction?
Hi, the correct permissions are those, that are correct from your point of view. No, the upgrade does not change your individual permissions to the "default" permissions. Regards, Ralf
On Thu, Jan 18, 2024 at 5:51 PM Jude DaShiell <jdashiel@panix.com> wrote:
warning: directory permissions differ on /usr/share/polkit-1/rules.d/ filesystem: 750 package: 755 (5/6) upgrading polkit [########################################################################] 100%warning: directory permissions differ on /usr/share/polkit-1/rules.d/ filesystem: 750 package: 755
What are correct permissions for these directories and has the upgrade corrected permissions that neede correction?
The permissions were recently changed to conform to upstream expectations. You can correct them on your system using: install -d -o root -g root -m 0755 /usr/share/polkit-1/rules.d
Am Thu, Jan 18, 2024 at 08:01:45PM +0100 schrieb Jan Alexander Steffens (heftig):
The permissions were recently changed to conform to upstream expectations. You can correct them on your system using:
install -d -o root -g root -m 0755 /usr/share/polkit-1/rules.d
Not OP but thanks for your answer. So the default directory group and mode of /usr/share/polkit-1/rules.d have changed with https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/commit/6... but why doesn't pacman change the permissions at package upgrade? I read somewhere (a long time ago) why pacman does not do this but I cannot find it anymore... First I thought that maybe a (broken?) package did somehow change the owner/group/permission of /usr/share/polkit-1/rules.d but the permissions are exactly like defined in the PKGBUILD of systemd before the above commit (-o root -g 102 -m 0750)
On Thu, 2024-01-18 at 22:21 +0100, deMaio wrote:
why doesn't pacman change the permissions at package upgrade?
Hi, I am not an Arch developer, just another Arch user. Custom, unusual permissions may be required for a user's system. If upstream or an Arch developer sees reasons to change the permissions, then the user should follow them by manually adopting new default permissions if there is nothing against it from the user's point of view, just like a user adapts a configuration to a *.pacnew configuration from time to time. IMO permissions are similar to configurations. New configurations are required from time to time, but you don't want that a package upgrade does overwrite your configurations. Regards, Ralf
PS: Have you never been bitten by an /etc/foo.d/99.conf that made other configurations null and void? The *.pacnew approach fails when a package introduces a new configuration through a drop-in file. The advantage of a drop-in file is that it can automatically add something new, but the disadvantage is that it can compete with and override an important configuration. IMO permissions are configurations as well. Changing a configuration automatically very seldom is a good thing.
Hi Ralf,
why doesn't pacman change the permissions at package upgrade? ... Custom, unusual permissions may be required for a user's system.
Yes.
IMO permissions are similar to configurations. New configurations are required from time to time, but you don't want that a package upgrade does overwrite your configurations.
Say my first install of a package creates /etc/p.conf. I don't edit it. Then the package is upgraded; upstream provide an altered p.conf. I'd expect p.conf to be changed and I think that's what happens. Similarly, if the package made a directory on installation and I left its permissions untouched then an upstream change of permissions should flow down to me. Only if I've moved away from the old upstream should the permission-change be skipped. Perhaps there's another reason why pacman doesn't pass on upstream permission changes. -- Cheers, Ralph.
On Fri, 2024-01-19 at 11:08 +0000, Ralph Corderoy wrote:
Say my first install of a package creates /etc/p.conf. I don't edit it. Then the package is upgraded; upstream provide an altered p.conf. I'd expect p.conf to be changed and I think that's what happens.
Similarly, if the package made a directory on installation and I left its permissions untouched then an upstream change of permissions should flow down to me. Only if I've moved away from the old upstream should the permission-change be skipped.
Perhaps there's another reason why pacman doesn't pass on upstream permission changes.
Hi Ralph, here IMO is a tiny difference between untouched permissions and untouched configurations. I have to admit that I don't have a real example at hand, but unpleasant things are conceivable. Regards, Ralf
participants (5)
-
deMaio
-
Jan Alexander Steffens (heftig)
-
Jude DaShiell
-
Ralf Mardorf
-
Ralph Corderoy