Bugzilla – Bug 1099347
changed system file permissions on upgrade
Last modified: 2018-06-28 18:27:23 UTC
I noticed a couple of config files becoming world readable
setting /etc/syslog.conf to root:root 0644. (wrong permissions 0600)
setting /etc/ssh/sshd_config to root:root 0640. (wrong permissions 0600)
and a couple of suid binaries becoming world executable
setting /usr/bin/crontab to root:trusted 4755. (wrong permissions 4750)
setting /sbin/pccardctl to root:trusted 4755. (wrong permissions 4750)
this does not look right
Hello and thank you for the report.
What kind of upgrade did you make?
It looks like the type of security settings for your system changed. By
default the "easy" settings are used. These are the settings that have been
applied here. The old permissions have been from the "secure" settings.
The configuration is found in /etc/sysconfig/security in item
"PERMISSION_SECURITY". You can find the different permissions used for easy
and secure in /etc/permissions.easy and /etc/permissions.secure, respectively.
I did upgrade of a Tumbleweed I was not running for a while to current snapshot.
The PERMISSION_SECURITY is set to "easy local".
I am not aware of changing this file.
I suppose changing the file to "secure local" will change the files back on next upgrade.
And given the settings are not applied immediately it is not clear when the settings changed.
Changing the settings changes the permissions of newly installed packages so I suppose this is working as expected with current Tumbleweed.
Thanks for looking into this.
You can reapply the security settings after changing /etc/sysconfig/security,
by running `chkstat --system`.
I think nothing really changed in your system. What you were seeing in the
logs have just been artifacts. When you install e.g. the cronie package then it
installs /usr/bin/crontab with some set of default permissions. After that
happened, chkstat is run automatically an applies the current security
settings. That's where the messages are coming from. So there's no need to
When you change the setting to 'secure' then a couple of setuid binaries
aren't accessible to regular users and you need to add users to the 'trusted'
group for them being able to run the setuid binaries. You need to be aware of
that in case something stops working as expected.
Right, and the packages are built with secure permissions but the default setting is easy so you get these unsetting messages about creating gaping security holes when installing packages.
I won't argue about sensible default here. So long as the 'secure' setting exists it's probably fine.