Hide Forgot
Description of problem: During fixing a security bug of wordpress (bug #1124582) I change the uid/gid/mode of the configuration (file + dir) I notice this is not applied during update Version-Release number of selected component (if applicable): rpm-4.11.2-2.fc20.x86_64 On RHEL-6 / RHEL-7 %attr of %dir is always applied. %attr of %config file is only applied if the file is not altered (which is perhaps the correct behavior). Before update $ rpm -V wordpress S.5....T. c /etc/wordpress/wp-config.php After update: $ rpm -V wordpress SM5...GT. c /etc/wordpress/wp-config.php On Fedora 20, if the directory contains an altered file, %attr is no applied. This could raise security issues on such update (wordpress 3.9.1 => 3.9.2 in testing) Especially as "verify" doesn't report any problem on the directory. Perhaps a better behavior could be If "uid/gid/mode" is unchanged by sysadmin (value of old RPM metadata), always applied value of the new rpm. => So, don't change the sysadmin choice. => Separate management of uid/gid/mode from file content.
Same issue in F19
The report seems a bit confused to me: half of it is talking about %attr of a %config file, and the other half including summary talks about containing directory. AFAICT this affects %config files only, the directory ownership is always updated (as the rpm -V output in original description indicates). Also AFAICT this affects all RHEL and Fedora versions, RHEL-7 is certainly expected to behave the same as current Fedora versions as rpm version is practically same. So yes there is a bug, content + permissions are too closely tied in the rpm internal machinery dealing with this stuff, but might be tough to fix in existing releases. Whether to honor sysadmin changes is a different kind of problem: on one hand you want to honor them, but OTOH you'd want rpm to fix accidentally incorrect permissions (especially on reinstall etc) and there's no way for rpm to know what is intentional and whats not.
(In reply to Panu Matilainen from comment #2) > The report seems a bit confused to me: half of it is talking about %attr of > a %config file, and the other half including summary talks about containing > directory. So forget about the config file, I was just trying to understand/describe the behavior. This bug report is only for %dir > AFAICT this affects %config files only, the directory ownership is always > updated (as the rpm -V output in original description indicates). Change in wordpress spec file (3.9.2-3, in updates-testing) -%dir %{_sysconfdir}/wordpress +%attr(750,root,apache) %dir %{_sysconfdir}/wordpress Test reproducer **** In Fedora 19 **** # yum install wordpress Installation : wordpress-3.9.1-1.fc19.noarch # ls -al /etc/wordpress drwxr-xr-x. 2 root root 4096 19 août 16:58 . drwxr-xr-x. 191 root root 12288 19 août 16:46 .. -rw-r--r--. 1 root root 3538 9 mai 06:49 wp-config.php # echo -e "\n\n" >>/etc/wordpress/wp-config.php # rpm -V wordpress S.5....T. c /etc/wordpress/wp-config.php # yum --enablerepo=updates-testing update wordpress Update: wordpress-3.9.2-3.fc19.noarch # rpm -V wordpress SM5...GT. c /etc/wordpress/wp-config.php => so /etc/wordpress is ok ? should be 750,root,apache ? # ls -al total 28 drwxr-xr-x. 2 root root 4096 19 août 16:59 . drwxr-xr-x. 191 root root 12288 19 août 16:46 .. -rw-r--r--. 1 root root 3541 19 août 17:00 wp-config.php => so owner/mode not changed during update (bug) => so report of --verify is not correct (bug) # rpm --setperms wordpress # rpm --setugids wordpress # ls -al total 28 drwxr-x---. 2 root apache 4096 19 août 16:59 . drwxr-xr-x. 191 root root 12288 19 août 16:46 .. -rw-r-----. 1 root apache 3541 19 août 17:00 wp-config.php => so the owner/mode are correctly defined in the RPM and restored. **** Same test with EPEL-7 **** After update from 3.9.1-1 to 3.9.1-3 # rpm -V wordpress SM5...GT. c /etc/wordpress/wp-config.php # ls -al drwxr-x---. 2 root apache 26 8 août 11:23 . drwxr-xr-x. 142 root root 8192 19 août 17:12 .. -rw-r--r--. 1 root root 3541 19 août 17:12 wp-config.php Owner/mode is what is expected. > Also AFAICT this affects all RHEL and Fedora versions, > RHEL-7 is certainly expected to behave the same as current > Fedora versions as rpm version is practically same. It seems it's not the case. RHEL-7 is not affected by this Fedora specific issue. > Whether to honor sysadmin changes is a different kind of problem: > on one hand you want to honor them, but OTOH you'd want rpm to fix > accidentally incorrect permissions (especially on reinstall etc) and > there's no way for rpm to know what is intentional and whats not. I agree. But having different behavior for dir and file is also not friendly ;)
I'm not able to reproduce, the new directory permissions are always applied. Please download the packages, run the following (adjust package paths as necessary) and attach the resulting /tmp/wp-upgrade.txt here. (rpm -e wordpress; rm -rf /etc/wordpress/; rpm -Uvh /tmp/wordpress-3.9.1-1.fc19.noarch.rpm;echo -e "\n\n" >>/etc/wordpress/wp-config.php >> /etc/wordpress/wp-config.php ; rpm -Uvvh --fsmdebug /tmp/wordpress-3.9.2-3.fc19.noarch.rpm ; ls -la /etc/wordpress) &> /tmp/wp-upgrade.txt
Created attachment 928619 [details] wp-upgrade.txt Everything is ok using rpm command. So this is a yum bug ?
Upgrade with yum is supposed to behave identically to upgrading with rpm, but there are have been (and are) cases where yum's test-transaction causes differences in some subtle cases. Can you reproduce the issue with the yum equivalent of the above? rpm -e wordpress; rm -rf /etc/wordpress; yum -y install wordpress; echo -e "\n\n" >>/etc/wordpress/wp-config.php >> /etc/wordpress/wp-config.php; yum --enablerepo=updates-testing -y --rpmverbosity=debug update wordpress; ls -la /etc/wordpress
Created attachment 928661 [details] wp-upgrade-yum.txt Output using yum, which reproduce the bug.
Okay, thanks for testing and with yum I can reproduce it too. And I can make sense of this all now... this is cured by the same thing that fixes bug 1076552, which has been fixed on rhel-7 but hasn't made its way to fedora yet, hence the difference between "almost identical" rpm versions.
rpm-4.11.3-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/rpm-4.11.3-1.fc20
Package rpm-4.11.3-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing rpm-4.11.3-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-10325/rpm-4.11.3-1.fc20 then log in and leave karma (feedback).
Will be nice to have in F19. Wordpress and phpMyAdmin (at least) are affected by permission changes (it seems someone have reported various bugs about bad permission on configuration dir, which is a security issue).
F19 will follow once the F20 update goes stable. Just a way of limiting potential damage in case anything goes wrong.
rpm-4.11.3-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/rpm-4.11.3-1.fc19
rpm-4.11.3-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
rpm-4.11.3-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.