[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140115163150.GG24286@brightrain.aerifal.cx>
Date: Wed, 15 Jan 2014 11:31:50 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: install.sh is wrong with libc.so
On Wed, Jan 15, 2014 at 08:48:18PM +0800, orc wrote:
> Szabolcs Nagy <nsz@...t70.net> пишет:
> >* orc <orc@...server.ru> [2014-01-15 16:42:08 +0800]:
> >> umask 077
> >> cat < lib/libc.so > /lib/libc.so.tmp.pid # /lib/libc.so.tmp.pid is
> >created with mode 600
> >> mv -f /lib/libc.so.tmp.pid /lib/libc.so
> >> chmod 755 /lib/libc.so # failed with "Permission denied"
> >>
> >> After that the system is unusable and requires external assistance.
> >
> >this is why you should have chmod statically linked
In fairness, my having chmod statically linked is why I didn't catch
this bug...
> I agree with that. For historical reasons it's not. But I expected
> musl will continue to use standard install program.
Unfortunately the "standard" (historical) install program is even more
dangerous; it truncates and overwrites the file in-place rather than
atomically renaming the new version over top of the old. This can
crash any programs currently running with the old version and could
even result in runaway random code execution. This was the motivation
for replacing it with musl's install.sh.
Regardless of that, I agree the current order (chmod after mv) is a
serious bug in atomicity of the install, and I apologize for the
breakage you experienced. I'm glad it got reported so we can fix it
before 1.0 though.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
