[BUG] System packages should not override existing permissions

[dwoz]

Description

Since adding the salt user and running the master as the new user we modify permissions on several directories and files when installing salt (deb and rpm packages). This works great but some users want to run the master as a user other than salt. In those cases; modifying the permissions at package install time cause users to have to re-adjust those permissions every time they upgrade salt.

Ideally the packages can be smart enough to not modify permissions if the target directories already exist and are owned by another user. Perhaps checking the permissions and only modifying them if they are owned by root is enough.

See also: #65243

[dwoz]

@barneysowood Thoughts or comments?

[OrangeDog]

Related: #65240, #65175, #65231, #65288

[barneysowood]

@dwoz - agreed, we shouldn't modify permissions on upgrade if they have been changed from the default. For 3006.2 to 3006.3, that was pretty tricky to do as the old permissions applied by the package needed to be changed. I think going forward, we should be stable on the permissions which should make it easier to work out if they have been changed and not modify on upgrade if so.

There's potentially some other options on how to handle this - certainly for the Debian packages, we could ask a question with debconf (with a sensible default) to check that the user installing wants to run the salt-master as salt (or another user or root) and as part of that process set permissions or not. I'm not sure what the RPM equivalent is but I'll look into it.

[colttt]

There is also an issue with git+ssh, per default salt-Home is /opt/saltstack/salt which contains .ssh/ after every upgrade the permission is set to root:root, so salt cannot access the git-repo until we change the permission of that folder