20230809 wrong permissions error and unsure how to report the problem
Although I am reporting this after updating to 20230809, these wrong permissions messages have occurred for a long time ( years ) For TW 20230809 the message was /usr/bin/fusermount3: setting to root:trusted 4755 (wrong permissions 4750) I cannot remember doing a TW update where I didn't receive a message about wrong permissions similar to that one. The issue is that these messages are wrong. I have confirmed this multiple times. When I update my test system and see these kinds of messages, I check the permissions on my main desktop system to see if they are wrong there ( they aren't ) Then when I update the main desktop system, I get the same messages for the files that I already confirmed were not wrong before doing the update. Here were the permissions on the main desktop system BEFORE updating to TW 20230809 which show that it was root:trusted 4755 -rwsr-xr-x 1 root trusted 35K Jul 17 13:34 /usr/bin/fusermount3 It seems that whatever does the permission check is what is broken but I am unsure what that is. Is this a known bug/problem? If not, any idea what I need to report the bug against ? Thanks! -- Regards, Joe
On 2023-08-10 21:16, Joe Salmeri wrote:
Although I am reporting this after updating to 20230809, these wrong permissions messages have occurred for a long time ( years )
For TW 20230809 the message was
/usr/bin/fusermount3: setting to root:trusted 4755 (wrong permissions 4750)
I cannot remember doing a TW update where I didn't receive a message about wrong permissions similar to that one.
The issue is that these messages are wrong.
I have confirmed this multiple times.
When I update my test system and see these kinds of messages, I check the permissions on my main desktop system to see if they are wrong there ( they aren't )
Then when I update the main desktop system, I get the same messages for the files that I already confirmed were not wrong before doing the update.
Here were the permissions on the main desktop system BEFORE updating to TW 20230809 which show that it was root:trusted 4755
-rwsr-xr-x 1 root trusted 35K Jul 17 13:34 /usr/bin/fusermount3
It seems that whatever does the permission check is what is broken but I am unsure what that is.
Is this a known bug/problem? If not, any idea what I need to report the bug against ?
Guess: The package comes with a set of permissions. At some point, "chkstat --system" runs. This was a script that was, in old times, part of SuSEconfig. This script checks permissions against a list, in /etc/permissions.easy and /etc/permissions.local by default. If the permissions in the just installed package do not match those in the list, they are changed, and it prints that message, "wrong permissions". As it fixes them, you do not see any problem when you check them. cer@Telcontar:~> grep /usr/bin/fusermoun /etc/permissions.easy /usr/bin/fusermount root:trusted 4755 /usr/bin/fusermount3 root:trusted 04755 cer@Telcontar:~> -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 8/10/23 16:11, Carlos E. R. wrote:
On 2023-08-10 21:16, Joe Salmeri wrote:
Although I am reporting this after updating to 20230809, these wrong permissions messages have occurred for a long time ( years )
For TW 20230809 the message was
/usr/bin/fusermount3: setting to root:trusted 4755 (wrong permissions 4750)
I cannot remember doing a TW update where I didn't receive a message about wrong permissions similar to that one.
The issue is that these messages are wrong.
I have confirmed this multiple times.
When I update my test system and see these kinds of messages, I check the permissions on my main desktop system to see if they are wrong there ( they aren't )
Then when I update the main desktop system, I get the same messages for the files that I already confirmed were not wrong before doing the update.
Here were the permissions on the main desktop system BEFORE updating to TW 20230809 which show that it was root:trusted 4755
-rwsr-xr-x 1 root trusted 35K Jul 17 13:34 /usr/bin/fusermount3
It seems that whatever does the permission check is what is broken but I am unsure what that is.
Is this a known bug/problem? If not, any idea what I need to report the bug against ?
Guess:
The package comes with a set of permissions.
At some point, "chkstat --system" runs. This was a script that was, in old times, part of SuSEconfig. This script checks permissions against a list, in /etc/permissions.easy and /etc/permissions.local by default. If the permissions in the just installed package do not match those in the list, they are changed, and it prints that message, "wrong permissions". As it fixes them, you do not see any problem when you check them.
cer@Telcontar:~> grep /usr/bin/fusermoun /etc/permissions.easy /usr/bin/fusermount root:trusted 4755 /usr/bin/fusermount3 root:trusted 04755 cer@Telcontar:~>
Hi Carlos, Thanks very much for that information as I was not sure what was doing the check. I get what it is doing, my point was that it is complaining that the permissions were WRONG, however, I checked them BEFORE I did the update because the message came up on a different TW system. So BEFORE I did the update to TW 20230809, the permissions where already 4755, however, when the update runs it complains that they are 4750 and says it is setting them to 4755. This was not a one time situation, I see this come up with pretty much every TW update I have ever done. Also, since I am using btrfs I can also look at the BEFORE snapshot which also confirms that permissions were 4755 before the update -rwsr-xr-x 1 root trusted 35K Jun 14 13:20 /.snapshots/2/snapshot/usr/bin/fusermount -rwsr-xr-x 1 root trusted 35K Aug 9 14:25 /usr/bin/fusermount3 So it would appear that checkstat has a bug in which it is incorrectly reporting the before permissions as 4750 when in fact that were really 4755. Actually I think you may have just pointed out what could be trigger the bug. permissions.easy has fusermount3 permissions as 04755 but shouldn't that be 4755 ? permissions.secure has fusermount3 permissions as 04750 but shouldn't that be 4750 ? Shouldn't permission values be 4 digits not 5 ? -- Regards, Joe
Well, seems like the permissions of the package are 0750 (just check by downloading the package). So: 1. the package updates and the permissions get set to 0750 (because these are the permissions inside the rpm) 2. the scripts checks, complains that its wrong and corrects it 3. repeat Am 10.08.23 um 23:39 schrieb Joe Salmeri:
On 8/10/23 16:11, Carlos E. R. wrote:
On 2023-08-10 21:16, Joe Salmeri wrote:
Although I am reporting this after updating to 20230809, these wrong permissions messages have occurred for a long time ( years )
For TW 20230809 the message was
/usr/bin/fusermount3: setting to root:trusted 4755 (wrong permissions 4750)
I cannot remember doing a TW update where I didn't receive a message about wrong permissions similar to that one.
The issue is that these messages are wrong.
I have confirmed this multiple times.
When I update my test system and see these kinds of messages, I check the permissions on my main desktop system to see if they are wrong there ( they aren't )
Then when I update the main desktop system, I get the same messages for the files that I already confirmed were not wrong before doing the update.
Here were the permissions on the main desktop system BEFORE updating to TW 20230809 which show that it was root:trusted 4755
-rwsr-xr-x 1 root trusted 35K Jul 17 13:34 /usr/bin/fusermount3
It seems that whatever does the permission check is what is broken but I am unsure what that is.
Is this a known bug/problem? If not, any idea what I need to report the bug against ?
Guess:
The package comes with a set of permissions.
At some point, "chkstat --system" runs. This was a script that was, in old times, part of SuSEconfig. This script checks permissions against a list, in /etc/permissions.easy and /etc/permissions.local by default. If the permissions in the just installed package do not match those in the list, they are changed, and it prints that message, "wrong permissions". As it fixes them, you do not see any problem when you check them.
cer@Telcontar:~> grep /usr/bin/fusermoun /etc/permissions.easy /usr/bin/fusermount root:trusted 4755 /usr/bin/fusermount3 root:trusted 04755 cer@Telcontar:~>
Hi Carlos,
Thanks very much for that information as I was not sure what was doing the check.
I get what it is doing, my point was that it is complaining that the permissions were WRONG, however, I checked them BEFORE I did the update because the message came up on a different TW system.
So BEFORE I did the update to TW 20230809, the permissions where already 4755, however, when the update runs it complains that they are 4750 and says it is setting them to 4755.
This was not a one time situation, I see this come up with pretty much every TW update I have ever done.
Also, since I am using btrfs I can also look at the BEFORE snapshot which also confirms that permissions were 4755 before the update
-rwsr-xr-x 1 root trusted 35K Jun 14 13:20 /.snapshots/2/snapshot/usr/bin/fusermount -rwsr-xr-x 1 root trusted 35K Aug 9 14:25 /usr/bin/fusermount3
So it would appear that checkstat has a bug in which it is incorrectly reporting the before permissions as 4750 when in fact that were really 4755.
Actually I think you may have just pointed out what could be trigger the bug.
permissions.easy has fusermount3 permissions as 04755 but shouldn't that be 4755 ?
permissions.secure has fusermount3 permissions as 04750 but shouldn't that be 4750 ?
Shouldn't permission values be 4 digits not 5 ?
-- Regards,
Joe
Sincerely Kilian Hanich
On 2023-08-10 23:50, Kilian Hanich wrote:
Well, seems like the permissions of the package are 0750 (just check by downloading the package).
So: 1. the package updates and the permissions get set to 0750 (because these are the permissions inside the rpm) 2. the scripts checks, complains that its wrong and corrects it 3. repeat
Right, that's how it works, since ever. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Thursday 2023-08-10 23:58, Carlos E. R. wrote:
On 2023-08-10 23:50, Kilian Hanich wrote:
Well, seems like the permissions of the package are 0750 (just check by downloading the package).
So: 1. the package updates and the permissions get set to 0750 (because these are the permissions inside the rpm) 2. the scripts checks, complains that its wrong and corrects it 3. repeat
Right, that's how it works, since ever.
And that won't change, really. System administrators can *choose and change* the permission strictness level of their installation, which can either be more strict or more lenient compared to the file permissions in an RPM package; in any case, there's always _some_ user where there's a mismatch (because RPMs can only store one mode). I guess a desirable course of action would just be to remove those messages from being emitted.
On 2023-08-11 00:09, Jan Engelhardt wrote:
On Thursday 2023-08-10 23:58, Carlos E. R. wrote:
On 2023-08-10 23:50, Kilian Hanich wrote:
Well, seems like the permissions of the package are 0750 (just check by downloading the package).
So: 1. the package updates and the permissions get set to 0750 (because these are the permissions inside the rpm) 2. the scripts checks, complains that its wrong and corrects it 3. repeat
Right, that's how it works, since ever.
And that won't change, really.
System administrators can *choose and change* the permission strictness level of their installation, which can either be more strict or more lenient compared to the file permissions in an RPM package; in any case, there's always _some_ user where there's a mismatch (because RPMs can only store one mode).
I guess a desirable course of action would just be to remove those messages from being emitted.
No, that shouldn't be done, the chkstat script outputs when it does a change by design. What can be done is having the rpm ship with the same permissions as "/etc/permissions.easy". The local administrator uses "/etc/permissions.local". But the packager has the choice of changing the permissions in the rpm, or doing that with chkstat later. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 8/10/23 20:06, Carlos E. R. wrote:
No, that shouldn't be done, the chkstat script outputs when it does a change by design.
What can be done is having the rpm ship with the same permissions as "/etc/permissions.easy". The local administrator uses "/etc/permissions.local".
But the packager has the choice of changing the permissions in the rpm, or doing that with chkstat later.
That is not quite true. If the packager sets the permissions to be SUID, rpmlint generates an error of 10000, and the package build fails. The only way to set SUID is through the permissions package. I agree that the warning sh9ould stay. Larry
On 2023-08-11 03:29, Larry Finger wrote:
On 8/10/23 20:06, Carlos E. R. wrote:
No, that shouldn't be done, the chkstat script outputs when it does a change by design.
What can be done is having the rpm ship with the same permissions as "/etc/permissions.easy". The local administrator uses "/etc/permissions.local".
But the packager has the choice of changing the permissions in the rpm, or doing that with chkstat later.
That is not quite true. If the packager sets the permissions to be SUID, rpmlint generates an error of 10000, and the package build fails. The only way to set SUID is through the permissions package.
Ah, that explains why the permissions have to be changed later :-)
I agree that the warning sh9ould stay.
Larry
-- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Friday 2023-08-11 03:06, Carlos E. R. wrote:
What can be done is having the rpm ship with the same permissions as "/etc/permissions.easy". The local administrator uses "/etc/permissions.local".
That would still generate warnings even if the admin chose to use /etc/sysconfig/security:PERMISSION_SECURITY="secure" I'm saying: there is no one right answer here. ("local" is not even in the picture.)
On 8/11/23 03:36, Jan Engelhardt wrote:
On Friday 2023-08-11 03:06, Carlos E. R. wrote:
What can be done is having the rpm ship with the same permissions as "/etc/permissions.easy". The local administrator uses "/etc/permissions.local". That would still generate warnings even if the admin chose to use
/etc/sysconfig/security:PERMISSION_SECURITY="secure"
I'm saying: there is no one right answer here. ("local" is not even in the picture.)
Which makes me curious as to whether people are using the default "easy" permissions or if they have changed them to "secure" or "paranoid" ? I realize that it is at the administrators discression but am curious as to whether people generally are changing to "secure" or "paranoid". I seem to recall some issues a year or so ago about someone reporting issues with changing it to one of the other 2 settings. -- Regards, Joe
On 8/10/23 18:09, Jan Engelhardt wrote:
On Thursday 2023-08-10 23:58, Carlos E. R. wrote:
On 2023-08-10 23:50, Kilian Hanich wrote:
Well, seems like the permissions of the package are 0750 (just check by downloading the package).
So: 1. the package updates and the permissions get set to 0750 (because these are the permissions inside the rpm) 2. the scripts checks, complains that its wrong and corrects it 3. repeat Right, that's how it works, since ever. And that won't change, really.
System administrators can *choose and change* the permission strictness level of their installation, which can either be more strict or more lenient compared to the file permissions in an RPM package; in any case, there's always _some_ user where there's a mismatch (because RPMs can only store one mode).
I guess a desirable course of action would just be to remove those messages from being emitted.
Thanks Jan, Carlos and others that have explained what is going on. Since the default install uses the easy permissions, would it make sense for the RPMs to match what the easy permissions are. If the admin switches to more restrictive permissions, then they would get the messages ( which makes sense to me ). -- Regards, Joe
On 8/11/23 09:49, Joe Salmeri wrote:
Thanks Jan, Carlos and others that have explained what is going on.
Since the default install uses the easy permissions, would it make sense for the RPMs to match what the easy permissions are.
If the admin switches to more restrictive permissions, then they would get the messages ( which makes sense to me ).
As I said in my previous posting, at least SUID permissions cannot be set in the spec file that builds an rpm. VirtualBox has a number of executables that must have permissions 4755, but if you try to set them in the rpm build, it blows up with a fatal error in the program name rpmlint, which checks for a number of errors. This behavior is by DESIGN, not an accident. If any package developer could set their package to have arbitrary permissions, the security holes would be huge. Instead, developers must have any such files included in the permissions package, and such inclusions are tightly controlled by the Security gurus at openSUSE. Speaking from experience, it is not easy to get a new file included, nor should it be. Getting an informational message is a minor thing. Larry
On 2023-08-11 18:58, Larry Finger wrote:
On 8/11/23 09:49, Joe Salmeri wrote:
Thanks Jan, Carlos and others that have explained what is going on.
Since the default install uses the easy permissions, would it make sense for the RPMs to match what the easy permissions are.
If the admin switches to more restrictive permissions, then they would get the messages ( which makes sense to me ).
As I said in my previous posting, at least SUID permissions cannot be set in the spec file that builds an rpm. VirtualBox has a number of executables that must have permissions 4755, but if you try to set them in the rpm build, it blows up with a fatal error in the program name rpmlint, which checks for a number of errors.
This behavior is by DESIGN, not an accident. If any package developer could set their package to have arbitrary permissions, the security holes would be huge. Instead, developers must have any such files included in the permissions package, and such inclusions are tightly controlled by the Security gurus at openSUSE. Speaking from experience, it is not easy to get a new file included, nor should it be.
You can probably package your own permissions in /etc/permissions.d/somefile ;-) -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Fri, 11 Aug 2023 11:58:04 -0500, Larry Finger <Larry.Finger@lwfinger.net> wrote:
On 8/11/23 09:49, Joe Salmeri wrote:
Thanks Jan, Carlos and others that have explained what is going on.
Since the default install uses the easy permissions, would it make sense for the RPMs to match what the easy permissions are.
If the admin switches to more restrictive permissions, then they would get the messages ( which makes sense to me ).
As I said in my previous posting, at least SUID permissions cannot be set in the spec file that builds an rpm. VirtualBox has a number of executables that must have permissions 4755, but if you try to set them in the rpm build, it blows up with a fatal error in the program name rpmlint, which checks for a number of errors.
This behavior is by DESIGN, not an accident. If any package developer could set their package to have arbitrary permissions, the security holes would be huge. Instead, developers must have any such files included in the permissions package, and such inclusions are tightly controlled by the Security gurus at openSUSE. Speaking from experience, it is not easy to get a new file included, nor should it be.
Getting an informational message is a minor thing.
Right, the word "error" does not appear in the message, correctly indicating that it is just informational, but because it says "wrong permissions", it can look like an error message: /usr/bin/fusermount3: setting to root:trusted 4755 (wrong permissions 4750) Since it is by design, the permissions are not really "wrong". They just need to be changed at that time. So why not change 'chkstat' to use another word, like "original", "package", "default", "given", etc. [permissions]? -- Robert Webb "I didn't get the wrong answer, it just needed to be changed."
Am 11.08.23 um 21:20 schrieb Robert Webb via openSUSE Factory:
Since it is by design, the permissions are not really "wrong". They just need to be changed at that time. So why not change 'chkstat' to use another word, like "original", "package", "default", "given", etc. [permissions]?
I was thinking the same. Getting rid of "wrong" should make this sound less like something went wrong. To add more proposals: "previous" or "existing", given that the original permissions are not necessarily those from a package. Aaron
On 8/12/23 11:30, Aaron Puchert wrote:
Am 11.08.23 um 21:20 schrieb Robert Webb via openSUSE Factory:
Since it is by design, the permissions are not really "wrong". They just need to be changed at that time. So why not change 'chkstat' to use another word, like "original", "package", "default", "given", etc. [permissions]?
I was thinking the same. Getting rid of "wrong" should make this sound less like something went wrong. To add more proposals: "previous" or "existing", given that the original permissions are not necessarily those from a package.
Aaron
I think you are on the right track, the current message lead me to believe something was really wrong and it was fixing it. I wondered why an update just installed something and the permissions were wrong and had to be fixed all the time. ( It happens quite a bit ). Then I looked at the before permissions ( which were correct ) and again wondered why the update installed with the wrong permissions which had to be fixed. After Larry's comment and explanation about not being able to SUID in an RPM ( and the security risk if they could ), and going from my memory about when this occurs, I am quite sure that was the most common situation when I see the wrong permissions message. I like the idea of saying something like "changing package permissions of ? to <permissions.easy or whatever> of ?' It would be nice if it could include where the change is coming from permissions.easy or whatever is causing the change to occur. -- Regards, Joe
On 8/11/23 12:58, Larry Finger wrote:
As I said in my previous posting, at least SUID permissions cannot be set in the spec file that builds an rpm. VirtualBox has a number of executables that must have permissions 4755, but if you try to set them in the rpm build, it blows up with a fatal error in the program name rpmlint, which checks for a number of errors.
This behavior is by DESIGN, not an accident. If any package developer could set their package to have arbitrary permissions, the security holes would be huge. Instead, developers must have any such files included in the permissions package, and such inclusions are tightly controlled by the Security gurus at openSUSE. Speaking from experience, it is not easy to get a new file included, nor should it be.
Getting an informational message is a minor thing.
Thanks Larry for your detailed explanation, that makes sense. -- Regards, Joe
On 11.08.2023 19:58, Larry Finger wrote:
On 8/11/23 09:49, Joe Salmeri wrote:
Thanks Jan, Carlos and others that have explained what is going on.
Since the default install uses the easy permissions, would it make sense for the RPMs to match what the easy permissions are.
If the admin switches to more restrictive permissions, then they would get the messages ( which makes sense to me ).
As I said in my previous posting, at least SUID permissions cannot be set in the spec file that builds an rpm.
user@uefi:~> rpm -q --dump -f /usr/sbin/unix_chkpwd | grep unix_chkpwd /usr/sbin/unix_chkpwd 26928 1691846723 1bfe8e2870486dc504a9ef5acf38da50d14b3bb602dc0f959865d395fc6c38fb 0104755 root shadow 0 0 0 X user@uefi:~> As you see, rpm has no problems packaging SUID file. %verify(not mode) %attr(4755,root,shadow) %{_sbindir}/unix_chkpwd %verify(not mode) %attr(4755,root,shadow) %{_sbindir}/unix2_chkpwd May be there are some white-/blacklist, I do not know.
On Tuesday 2023-08-29 20:09, Andrei Borzenkov wrote:
As I said in my previous posting, at least SUID permissions cannot be set in the spec file that builds an rpm.
user@uefi:~> rpm -q --dump -f /usr/sbin/unix_chkpwd | grep unix_chkpwd /usr/sbin/unix_chkpwd 26928 1691846723 1bfe8e2870486dc504a9ef5acf38da50d14b3bb602dc0f959865d395fc6c38fb 0104755 root shadow 0 0 0 X user@uefi:~>
As you see, rpm has no problems packaging SUID file.
%verify(not mode) %attr(4755,root,shadow) %{_sbindir}/unix_chkpwd
May be there are some white-/blacklist, I do not know.
rpmlint/checks/FilesCheck.py: self.output.add_info('E', pkg, 'setuid-binary', fname, user, '%o' % perm)
On 29.08.2023 21:35, Jan Engelhardt wrote:
On Tuesday 2023-08-29 20:09, Andrei Borzenkov wrote:
As I said in my previous posting, at least SUID permissions cannot be set in the spec file that builds an rpm.
user@uefi:~> rpm -q --dump -f /usr/sbin/unix_chkpwd | grep unix_chkpwd /usr/sbin/unix_chkpwd 26928 1691846723 1bfe8e2870486dc504a9ef5acf38da50d14b3bb602dc0f959865d395fc6c38fb 0104755 root shadow 0 0 0 X user@uefi:~>
As you see, rpm has no problems packaging SUID file.
%verify(not mode) %attr(4755,root,shadow) %{_sbindir}/unix_chkpwd
May be there are some white-/blacklist, I do not know.
rpmlint/checks/FilesCheck.py: self.output.add_info('E', pkg, 'setuid-binary', fname, user, '%o' % perm)
And how does it explain that pam package has SUID binary? This check is apparently filtered out by default in rpmlint/configs/openSUSE/opensuse.toml. This message is not present in pam build log.
Citeren Andrei Borzenkov <arvidjaar@gmail.com>:
rpmlint/checks/FilesCheck.py: self.output.add_info('E', pkg, 'setuid-binary', fname, user, '%o' % perm)
And how does it explain that pam package has SUID binary?
This check is apparently filtered out by default in rpmlint/configs/openSUSE/opensuse.toml. This message is not present in pam build log.
https://en.opensuse.org/openSUSE:Package_security_guidelines
Am 11.08.23 um 16:49 schrieb Joe Salmeri:
Since the default install uses the easy permissions, would it make sense for the RPMs to match what the easy permissions are.
If the admin switches to more restrictive permissions, then they would get the messages ( which makes sense to me ).
The documentation [1] says
Permissions attributes in the package should reflect the setting of the secure level (/etc/permissions.secure).
Packaging with easy permissions would lead to the easy ("insecure") settings being in effect for a brief window of time, which of course reduces security. So this seems unlikely to change. [1] <https://en.opensuse.org/openSUSE:Packaging_Conventions_RPM_Macros#%verify_permissions>
participants (9)
-
Aaron Puchert -
Andrei Borzenkov -
Arjen de Korte -
Carlos E. R. -
Jan Engelhardt -
Joe Salmeri -
Kilian Hanich -
Larry Finger -
Robert Webb