The question is what created the file with the wrong permissions. Please note that the rpm contents are irrelevant as the file is symlink in the package and symlinks do not really have permissions.

The update-crypto-policies tool from the crypto-policies package would not use such invalid permissions so it must be something else that creates the file with such permissions.

Reassigning to the potential component that might be the culprit.

In RHVH, we use 'rpm --setperms' in order to keep the original permissions, but it seems that when we use it we get 777 permissions.

Hmm, so the reason is that in 8.3 the file was changed from %config to %ghost file but it was kept as a symlink. And for some reason rpm for %ghost files does record 777 permissions of the symlink.

I don't see this as a bug in crypto-policies though. We could somehow workaround it in the crypto-policies package but apparently it is not a good idea to use the rpm --setperms.

A symlink will always have 777, and `rpm --setperms` is the way to reset package permissions, so If an admin calls this, they would expect the system to behave correctly.  In the case of calling update-crypto-policies to generate a real 644 file and then calling setperms, it would break the system.  Why not keep it as %ghost 644 without a symlink ?

It is then a bug in rpm that it applies permissions that are meant to be applied to symlink to a regular file. It is a complete nonsense to do that.

Good point, rpm could check this also, but as package maintainers if we have 2 possibilities, real file with 644 and a symlink with 777, it could be better to package the ghost as a real file with 644, especially when chmod on the 777 symlink to 644 as in the case of setperms will have no affect (I didn't test this though, so it's just a thought)

Tomas, could you please help me understand what the issue is with rpm here?

AFAICT, "rpm --setperms" does what it's supposed to do - it sets the permissions on the individual files according to what's recorded in the rpmdb.  It actually is just a popt alias which calls chmod(1) behind the scenes.

Now, when it comes to symlinks, permissions on them are irrelevant on Linux, see chmod(1):

---8<---
chmod never changes the permissions of symbolic links; the chmod system call cannot change their permissions. This is not a problem since the permissions of symbolic links are never used. However, for each symbolic link listed on the command line, chmod changes the permissions of the pointed-to file. In contrast, chmod ignores symbolic links encountered during recursive directory traversals.
---8<---

More info also here: https://superuser.com/a/303063

> However, for each symbolic link listed on the command line, chmod changes the permissions of the pointed-to file.

AIUI that exactly is the issue: rpm invokes chmod in a way that causes a regular file to receive the permissions of a symlink, which indeed is completely non-sensical.

There was a nasty regression in rpm 4.14.2 that caused --setperms and --setugids to follow links but it's supposedly fixed in rpm >= 4.14.2-4. What version of rpm is this, exactly?

You're right - I missed the following little detail in Comment 0:

# ll /etc/crypto-policies/back-ends/openssh.config
-rwxrwxrwx. 1 root root 480 Nov 20 14:56 /etc/crypto-policies/back-ends/openssh.config
^

Indeed, this is not a symlink, though still has the 777 mode.  In my testing, I had a real symlink there, so such perms were kinda expected there.

I'll keep looking then.

Keeping the needinfo on Tomas for the RPM version.

Eh... sorry, it should've been on Asaf instead, correcting.

I believe it is the rpm from RHEL-8.3 compose. rpm-4.14.3-4.el8.x86_64.rpm 

However I think there is one more thing in play here - the symlink in the package is %gost file. Maybe this is the reason why the permissions are applied?

s/%gost/%ghost/ of course

(In reply to Michal Domonkos from comment #10)
> Keeping the needinfo on Tomas for the RPM version.

the RPM version rpm-4.14.3-4.el8

I think Tomas has it right - FILEFLAGS for a normal symlink is 0, but for ghost symlink it is set to 64 which triggers the chmod.  The file in this package may be either a symlink or a normal file - if the file is changed from a symlink to normal file, and then we run setperms, it will apply the permissions of the symlink (777) on the normal file.

Btw, if you want to reproduce this:

1. move the symlink aside (for testing)
2. touch a file with 644
3. run rpm --setperms on the crypto-policies package
4. check the permissions on that file, you'll see they changed to 777

Upstream PR created:
https://github.com/rpm-software-management/rpm/pull/1854

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (rpm bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:2082