Bug#905939: tzdata files can get corrupted via write to /etc/localtime

[Vincent Lefevre]

On 2018-08-12 22:05:00 +0200, Aurelien Jarno wrote:
> The switch to a symlink has been done so that systemd (#803144), and
> recent desktop environments can work on Debian. On other distributions
> /etc/timezone does not exist and the timezone configuration can be
> checked by looking where the symlink points to.

OK, I've checked FHS 3.0, and it explicitly allows symbolic links
in /etc.

> In summary I don't believe there is a bug in tzdata. The bug should be
> reassigned to the package wrongly changing /etc/localtime.

I'll try to get information from the administrator of the machine
about this.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Git][glibc-team/glibc][glibc-2.28] 2 commits: debian/patches/git-updates.diff: update from upstream stable branch.

[Aurelien Jarno]

Aurelien Jarno pushed to branch glibc-2.28 at GNU Libc Maintainers / glibc


Commits:
7f396537 by Aurelien Jarno at 2018-08-12T21:44:40Z
debian/patches/git-updates.diff: update from upstream stable branch.

- - - - -
7c975606 by Aurelien Jarno at 2018-08-12T21:44:40Z
Close a few bugs

- - - - -


4 changed files:

- debian/changelog
- + debian/patches/git-updates.diff
- − debian/patches/hurd-i386/git-htl-getspecific.diff
- debian/patches/series


View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/compare/e5c069a354f6a7c0945f3f81598192b8307d27df...7c9756061d5635862871684a61f464d6ea4c6a2b

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/glibc/compare/e5c069a354f6a7c0945f3f81598192b8307d27df...7c9756061d5635862871684a61f464d6ea4c6a2b
You're receiving this email because of your account on salsa.debian.org.

Bug#905939: tzdata files can get corrupted via write to /etc/localtime

[Aurelien Jarno]

On 2018-08-12 03:24, Vincent Lefevre wrote:
> Package: tzdata
> Version: 2018e-0+deb9u1
> Severity: important
> 
> On a Debian 9 machine:
> 
> patate:~> TZ=UTC date; TZ=UTC0 date
> Sun Aug 12 03:02:35 CEST 2018
> Sun Aug 12 01:02:35 UTC 2018
> 
> The first line is based on the /usr/share/zoneinfo/UTC file according
> to strace, but this is wrong as CEST is not UTC. The file is:
> 
> -rw-r--r-- 1 root root 2971 2018-05-15 10:01:38 /usr/share/zoneinfo/UTC
> 
> which doesn't seem to be the original one. I assume that it got
> corrupted via a write to /etc/localtime, but /etc/localtime is
> a symlink to /usr/share/zoneinfo/Etc/UTC, which is itself a
> symlink to /usr/share/zoneinfo/UTC.
> 
> Now, could the write to /etc/localtime be regarded as a bug?
> Probably not, because /etc/localtime is a config file, and one
> is allowed to write to config files under /etc.

I don't think it should be regarded as a bug. The fact it's a conffile
means that you can replace the symlink by another one or by a file, and
that dpkg and the maintainer script should keep the changes. It doesn't
mean anything about what the user can do about it.

> In short, having a symlink from a file under /etc to a file from
> a package does not seem to be correct.

This is nothing new, on a normal installation there are hundred of links
in /etc pointing to a file under /usr. For me the bug is in the
application writing the content instead of replacing the symlink.

> BTW, on https://www.virtualmin.com/node/15246 someone mentioned
> another issue with a symlink: "It's not really wise to make
> /etc/localtime a symlink. That used to be the standard behavior for
> Linux in the past, but then someone realized that /usr/share/zoneinfo
> could be on a different volume that's not always mounted, and we
> definitely don't want to be without /etc/localtime, [...]"

This is used to be a copy, to handle the case where /usr is mounted late
in the boot script. Since Jessie (initramfs-tools 0.117), it is
guaranteed that /usr is mounted in the initramfs, so it's possible to
use a symlink.

The switch to a symlink has been done so that systemd (#803144), and
recent desktop environments can work on Debian. On other distributions
/etc/timezone does not exist and the timezone configuration can be
checked by looking where the symlink points to.

In summary I don't believe there is a bug in tzdata. The bug should be
reassigned to the package wrongly changing /etc/localtime.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)

[Alexis Murzeau]

On 12/08/2018 15:55, Jackie wrote:
> Great. It works. 
> To make it clear, this is what I did to test:
> 
> 1. Install libopenblas-base:amd64 (0.3.2+ds-1) and libopenblas-dev:amd64
> (0.3.2+ds-1) from official repo. After installation complete, open a
> terminal and type gimp + ENTER. The cmd hangs forever and Ctrl-C gets a
> segment fault.
> 2. sudo apt purge libopenblas-base libopenblas-dev. Upon finish, open a
> terminal and type gimp + ENTER. Gimp lanuches without problem.
> 3. Add the repo you offered and install libopenblas-base:amd64
> (0.3.2+ds-1.1~1patchTLS) and libopenblas-dev:amd64
> (0.3.2+ds-1.1~1patchTLS). The installations go well, after that, open a
> terminal and type gimp + ENTER.  Gimp again lanuches without any problem.
> 
> I think this validates both the existence of the bug and your solution.
> Thank you very much.

Thank you too for testing that patch :)
Good to see it works for others having the gimp hang too.

> 
> Jiang Jun


-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)

[Jackie]

Great. It works.
To make it clear, this is what I did to test:

1. Install libopenblas-base:amd64 (0.3.2+ds-1) and 
libopenblas-dev:amd64 (0.3.2+ds-1) from official repo. After 
installation complete, open a terminal and type gimp + ENTER. The cmd 
hangs forever and Ctrl-C gets a segment fault.
2. sudo apt purge libopenblas-base libopenblas-dev. Upon finish, open a 
terminal and type gimp + ENTER. Gimp lanuches without problem.
3. Add the repo you offered and install libopenblas-base:amd64 
(0.3.2+ds-1.1~1patchTLS) and libopenblas-dev:amd64 
(0.3.2+ds-1.1~1patchTLS). The installations go well, after that, open a 
terminal and type gimp + ENTER.  Gimp again lanuches without any 
problem.


I think this validates both the existence of the bug and your solution. 
Thank you very much.


Jiang Jun

On Sun, Aug 12, 2018 at 9:31 PM, Alexis Murzeau  
wrote:

On 10/08/2018 23:27, Alexis Murzeau wrote:
 I can provide a binary package that include this patch, but I'm not 
sure
 this is the best thing to do (I'm not the official maintainer, nor 
know

 a good place to upload it).



As I was requested to provide binary package to test the patch, I'm
providing this as version `0.3.2+ds-1.1~1patchTLS` built with sbuild 
at [0].


Instructions are on the same page [0]:
execute: `apt-key adv --keyserver hkps://hkps.pool.sks-keyservers.net
--recv-keys 0x3F7A2FA142E434FE06622560B05266B2EB68F001`
and add `deb https://amurzeau.github.io/apt-repository unstable main` 
to

sources.list.

This APT repository contains both the source and amd64 binary 
packages.

If you try it, please tell if it works.

[0] https://amurzeau.github.io/apt-repository/

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F

Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)

[Alexis Murzeau]

On 10/08/2018 23:27, Alexis Murzeau wrote:
> I can provide a binary package that include this patch, but I'm not sure
> this is the best thing to do (I'm not the official maintainer, nor know
> a good place to upload it).
> 

As I was requested to provide binary package to test the patch, I'm
providing this as version `0.3.2+ds-1.1~1patchTLS` built with sbuild at [0].

Instructions are on the same page [0]:
execute: `apt-key adv --keyserver hkps://hkps.pool.sks-keyservers.net
--recv-keys 0x3F7A2FA142E434FE06622560B05266B2EB68F001`
and add `deb https://amurzeau.github.io/apt-repository unstable main` to
sources.list.

This APT repository contains both the source and amd64 binary packages.
If you try it, please tell if it works.

[0] https://amurzeau.github.io/apt-repository/

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature