[Bug 1172521] New: timezone modifies a file below /usr/share
http://bugzilla.suse.com/show_bug.cgi?id=1172521 Bug ID: 1172521 Summary: timezone modifies a file below /usr/share Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs@suse.de Reporter: kukuk@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- %post if [ ! -L /usr/share/zoneinfo/posixrules ]; then rm -f /usr/share/zoneinfo/posixrules ln -sf /etc/localtime /usr/share/zoneinfo/posixrules fi if [ -e /usr/share/zoneinfo/posixrules.rpmnew ]; then rm -f /usr/share/zoneinfo/posixrules.rpmnew fi %files %defattr(-,root,root) %verify(not link md5 size mtime) %config(missingok,noreplace) /etc/localtime %verify(not link md5 size mtime) %{_datadir}/zoneinfo/posixrules With read-only root filesystems and transactional-updates, this is a bad idea. Since this is pretty old code looking like some update cleanup, I question if we need that at all or couldn't remove it completely. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1172521
Thorsten Kukuk
http://bugzilla.suse.com/show_bug.cgi?id=1172521
http://bugzilla.suse.com/show_bug.cgi?id=1172521#c2
--- Comment #2 from Thorsten Kukuk
Upgrading to the 2020-06-02 Tumbleweed snapshot resulted in the creation of a /etc/localtime.rpmnew link to /usr/share/zoneinfo/UTC, I suspect because of this. Luckily, it didn't overwrite my existing /etc/localtime link to /usr/share/zoneinfo/America/Los_Angeles.
You got a "*.rpmnew" file, so everything is fine and working as expected and designed. This means: /etc/localtime was changed in the package, but since you changed it, your changes got not overwritten. And never will be ("config noreplace"). So it did not overwrite your existing file "luckily", but by design. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1172521
http://bugzilla.suse.com/show_bug.cgi?id=1172521#c3
--- Comment #3 from Marketa Calabkova
%post if [ ! -L /usr/share/zoneinfo/posixrules ]; then rm -f /usr/share/zoneinfo/posixrules ln -sf /etc/localtime /usr/share/zoneinfo/posixrules fi if [ -e /usr/share/zoneinfo/posixrules.rpmnew ]; then rm -f /usr/share/zoneinfo/posixrules.rpmnew fi
from changelog 2016g: """ * The following change was previously patched in the package and is now upstream: + If the installed localtime and/or posixrules files are symbolic links, zic now keeps them symbolic links when updating them, for compatibility with platforms like openSUSE where other programs configure these files as symlinks. + zic now avoids hard linking to symbolic links, avoids some unnecessary mkdir and stat system calls, and uses shorter file names internally. + Drop the patches: ... """ Maybe the changes were part of the fix, but they were forgotten? Just a guess.
With read-only root filesystems and transactional-updates, this is a bad idea.
What exactly is a bad idea, please?
Since this is pretty old code looking like some update cleanup, I question if we need that at all or couldn't remove it completely.
"pretty old"? How old? Could you please point me to an exact revision? AFAIK there is no "osc blame", so I can not find it myself. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1172521
http://bugzilla.suse.com/show_bug.cgi?id=1172521#c4
--- Comment #4 from Thorsten Kukuk
Maybe the changes were part of the fix, but they were forgotten? Just a guess.
I don't know, could be.
With read-only root filesystems and transactional-updates, this is a bad idea.
What exactly is a bad idea, please?
Everything below /usr should never be modified by a script, at runtime or anything else. You even don't know if it is possible or not. Additional, this prevents from checking /usr if somebody tampered with it or not
Since this is pretty old code looking like some update cleanup, I question if we need that at all or couldn't remove it completely.
"pretty old"? How old? Could you please point me to an exact revision? AFAIK there is no "osc blame", so I can not find it myself.
I don't know a tool, but you can go through the SLE11 maintanence updates and search for the first update introducing this code. According to the changes file it looks like it's from 2012. It was introduced with an SLES11 update, so there should be no system outside anymore which needs this code. So the %post will never be executed again and can be removed, including the PreReq line. Another question is the "%verify(not link md5 size mtime) %{_datadir}/zoneinfo/posixrules" line. This prevents our tools to find out if somebody tampered with /usr. Which is already bad. As this file is coming from the package itself, I don't see a need for it. Another question coming up is: does zic or something else modifies this file? If yes, we need another solution for this, with "Carwos", "MicroOS", "Kubic", "Transactional Server", /usr is read-only and this file cannot be modified by the admin. Another reason why the %verify statement is bad: it prevents us from finding such cases early, where tools modify data below /usr and fix them. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1172521
http://bugzilla.suse.com/show_bug.cgi?id=1172521#c5
--- Comment #5 from Marketa Calabkova
With read-only root filesystems and transactional-updates, this is a bad idea.
What exactly is a bad idea, please?
Everything below /usr should never be modified by a script, at runtime or anything else. You even don't know if it is possible or not. Additional, this prevents from checking /usr if somebody tampered with it or not
oh, sorry, I have overlooked that it actually happens in %post...
So the %post will never be executed again and can be removed, including the PreReq line.
With the fix from 2016g it should at least be never executed twice :) . Removing the %post phase could cause some problems only to the systems where these files are not symlinks, so (according to you) systems which were last updated 10 years ago. Yes, there should be no such running system. Regarding the "PreReq: filesystem, coreutils": I see why it can be removed. Just by curiosity: Is it even possible that a system does not have these packages later than at the very beginning?
Another question is the "%verify(not link md5 size mtime) %{_datadir}/zoneinfo/posixrules" line. This prevents our tools to find out if somebody tampered with /usr. Which is already bad. As this file is coming from the package itself, I don't see a need for it.
What does this %verify actually do, please?
Another question coming up is: does zic or something else modifies this file? If yes, we need another solution for this, with "Carwos", "MicroOS", "Kubic", "Transactional Server", /usr is read-only and this file cannot be modified by the admin. Another reason why the %verify statement is bad: it prevents us from finding such cases early, where tools modify data below
From zic manual page:
""" -p timezone Use timezone's rules when handling nonstandard TZ strings like "EET-2EEST" that lack transition rules. zic will act as if the input contained a link line of the form Link timezone posixrules """ zic.8.txt contains more information about this option: """ This feature is obsolete and poorly supported. Among other things it should not be used for timestamps after the year 2037, and it should not be combined with -b slim if timezone's transitions are at standard time or Universal Time (UT) instead of local time. """ Yes, it could relink the symlink. And I wonder why this "obsolete" notice isn't in an installed man page... More of this, we actually use this feature in our spec file to generate posixrules. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1172521
http://bugzilla.suse.com/show_bug.cgi?id=1172521#c6
--- Comment #6 from Thorsten Kukuk
(In reply to Thorsten Kukuk from comment #4)
So the %post will never be executed again and can be removed, including the PreReq line.
With the fix from 2016g it should at least be never executed twice :) . Removing the %post phase could cause some problems only to the systems where these files are not symlinks, so (according to you) systems which were last updated 10 years ago. Yes, there should be no such running system.
SLES 11 SP4, SLES12 and SLES15 have this code, so everybody updating from them has in every case a "fixed" system. An upgrade from an older version (like SLES 11 SP3) is not supported.
Regarding the "PreReq: filesystem, coreutils": I see why it can be removed. Just by curiosity: Is it even possible that a system does not have these packages later than at the very beginning?
filesystem is always installed due to other dependencies, but in the end not really required, as RPM will create the directories you need. coreutils is not necessary installed, there are alternate implementations possible like busybox-coreutils. If the %post is removed, the timezone package does not need them anyways. But if %post stays, the "PreReq: coreutils" has to be replaced with "Requires(post): /usr/bin/rm /usr/bin/ln", as this is what the package needs.
Another question is the "%verify(not link md5 size mtime) %{_datadir}/zoneinfo/posixrules" line. This prevents our tools to find out if somebody tampered with /usr. Which is already bad. As this file is coming from the package itself, I don't see a need for it.
What does this %verify actually do, please?
The %verify tells rpm what it should do if you call "rpm -V". So this case, rpm -V timezone will not verify, if the content of the link, the md5 checksum, size or mtime has changed compared what got installed from the package.
Yes, it could relink the symlink. And I wonder why this "obsolete" notice isn't in an installed man page... More of this, we actually use this feature in our spec file to generate posixrules.
The usage of "zic" in the build section is correct, and in the %install section we have: ln -sf /etc/localtime %{buildroot}%{_prefix}/share/zoneinfo/posixrules So removing the %verify from %{_prefix}/share/zoneinfo/posixrules should be Ok, don't see why it should be needed with the current package. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1172521
http://bugzilla.suse.com/show_bug.cgi?id=1172521#c7
--- Comment #7 from Marketa Calabkova
So removing the %verify from %{_prefix}/share/zoneinfo/posixrules should be Ok, don't see why it should be needed with the current package.
I can confirm that removing this whole line (since zoneinfo itself is included in the %files section) doesn't produce any "rpm -V" output. Removing the %verify from /etc/localtime makes "rpm -V" complain. Based on our discussion I have changed few things in Base:System/timezone (see latest commit). Please review and let me know whether you are satisfied with the changes. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1172521
http://bugzilla.suse.com/show_bug.cgi?id=1172521#c8
--- Comment #8 from Thorsten Kukuk
Based on our discussion I have changed few things in Base:System/timezone (see latest commit). Please review and let me know whether you are satisfied with the changes.
Looks good to me. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1172521
http://bugzilla.suse.com/show_bug.cgi?id=1172521#c9
--- Comment #9 from Marketa Calabkova
http://bugzilla.suse.com/show_bug.cgi?id=1172521
http://bugzilla.suse.com/show_bug.cgi?id=1172521#c10
--- Comment #10 from OBSbugzilla Bot
http://bugzilla.suse.com/show_bug.cgi?id=1172521
http://bugzilla.suse.com/show_bug.cgi?id=1172521#c11
Dominique Leuenberger
Since this is pretty old code looking like some update cleanup, I question if we need that at all or couldn't remove it completely.
"pretty old"? How old? Could you please point me to an exact revision? AFAIK there is no "osc blame", so I can not find it myself.
There actyally IS osc blame:
osc blame openSUSE:Factory timezone timezone.spec
1 (unknown 2007-08-09 10:05:51 91) %post 64 (namtrac 2012-09-14 10:40:45 92) if [ ! -L /usr/share/zoneinfo/posixrules ]; then 64 (namtrac 2012-09-14 10:40:45 93) rm -f /usr/share/zoneinfo/posixrules 64 (namtrac 2012-09-14 10:40:45 94) ln -sf /etc/localtime /usr/share/zoneinfo/posixrules 64 (namtrac 2012-09-14 10:40:45 95) fi 64 (namtrac 2012-09-14 10:40:45 96) if [ -e /usr/share/zoneinfo/posixrules.rpmnew ]; then 64 (namtrac 2012-09-14 10:40:45 97) rm -f /usr/share/zoneinfo/posixrules.rpmnew 64 (namtrac 2012-09-14 10:40:45 98) fi
NOTE: 'namtrac' was the user performing the checkin to openSUSE:Factory, not the user performing the change. osc log openSUSE:Factory timezone | grep r64 r64 | namtrac | 2012-09-14 10:40:45 | 31e18058332c8b031d5431080d4a5b05 | 2012f | rq134187 => change came to Factory via SR 134187; osc rq show -d 134187 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1172521
http://bugzilla.suse.com/show_bug.cgi?id=1172521#c13
Marketa Calabkova
That said, I see that there have been fixes applied. Perhaps this issue has been resolved?
It will be resolved as soon as the request https://build.opensuse.org/request/show/811896 makes it into Factory (it is now stuck in a complicated staging project). But yes, we could consider it resolved. I will mark it so if you do not mind. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com