install.sh is wrong with libc.so

install.sh is wrong with libc.so

[orc]

In case of executable files (which libc.so is), install.sh is wrong and dangerous.

The sequence of commands of install.sh from 0.9.15:

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.

Re: install.sh is wrong with libc.so

[Laurent Bercot]

> 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"

  Very funny bug ^^
  I'm curious of the thought process behind that code:
  - why cat instead of cp ? I guess it's to avoid the implementation-defined behaviour
of cp wrt. rights of the destination file, whereas >'s behaviour is guaranteed.
  - but an explicit chmod is needed anyway.
  - why perform the chmod after the mv, since mv is guaranteed to be a rename() in that
case, the rights will be preserved ? Is there a possibility of someone abusing the
temp file if it is 0755, knowing it is owned by root anyway ?

  chmoding the temp file before the mv -f, instead of /lib/libc.so at the end, looks
like the obvious and simplest fix, but I'm wondering whether I missed something.

-- 
  Laurent

Re: install.sh is wrong with libc.so

[Christian Wiese]

[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]

Hi,

On Wed, 15 Jan 2014 16:42:08 +0800
orc <orc@sibserver.ru> wrote:

> In case of executable files (which libc.so is), install.sh is wrong
> and dangerous.
Just for curiosity, what do you mean in particular to be "dangerous"?
> 
> The sequence of commands of install.sh from 0.9.15:
> 
> 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"

I just checked the build logs on my own musl based builds that are
installing things into a dedicated "sysroot directory" for that build,
and the install just works fine.
I think what you are doing is calling 'make install' as a non-root
user which will obviously fail.
What I do not really get is why a normal user should be able to install
a '/lib/lbc.so' anyway. That somehow feels more dangerous to me, but
maybe I do not get the whole picture here, as you just provided some
snippets and you are not telling us how your build process actually
looks like.

I think the info about how you are building would be quite helpful.

Cheers,
Chris



-- 
PGP Fingerprint: F96B A15F DF25 2B3E 49CB BA16 241B F3E7 52FE AFC6

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: install.sh is wrong with libc.so

[orc]

Christian Wiese <chris@opensde.net> пишет:
>Hi,
>
>On Wed, 15 Jan 2014 16:42:08 +0800
>orc <orc@sibserver.ru> wrote:
>
>> In case of executable files (which libc.so is), install.sh is wrong
>> and dangerous.
>Just for curiosity, what do you mean in particular to be "dangerous"?

Dangerous in case after performing installation, dynamic linked system becomes unusable: no logins are accepted, no shell can be spawned, even self-boot with init= kernel command line will give you nothing but a kernel panic.
(Of course I should have a static linked busybox, but I even did not expected such a change will occur since 0.9.12)

>> 
>> The sequence of commands of install.sh from 0.9.15:
>> 
>> 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"
>
>I just checked the build logs on my own musl based builds that are
>installing things into a dedicated "sysroot directory" for that build,
>and the install just works fine.
>I think what you are doing is calling 'make install' as a non-root
>user which will obviously fail.
>What I do not really get is why a normal user should be able to install
>a '/lib/lbc.so' anyway. That somehow feels more dangerous to me, but
>maybe I do not get the whole picture here, as you just provided some
>snippets and you are not telling us how your build process actually
>looks like.
>
>I think the info about how you are building would be quite helpful.

I did installation as root user. I also do not run restrictive/hardened kernels.
Sorry I lost log of installation, but after installing 0.9.15' libc.so "make install" refused to run with "Permission denied" error. Rest is simple: no command can be executed, login attempts refused, symptoms like "rm -fr /" was executed, only with "Permission denied".
Only boot from rescue flash drive with prepared initrd showed that /lib/libc.so was half-installed with mode 600.

>
>Cheers,
>Chris

Re: install.sh is wrong with libc.so

[Szabolcs Nagy]

* orc <orc@sibserver.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

but this should be fixed so there is no window during
the update where dynamically linked binaries fail

Re: install.sh is wrong with libc.so

[orc]

Szabolcs Nagy <nsz@port70.net> пишет:
>* orc <orc@sibserver.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

I agree with that. For historical reasons it's not. But I expected musl will continue to use standard install program.

>
>but this should be fixed so there is no window during
>the update where dynamically linked binaries fail

Re: install.sh is wrong with libc.so

[Christian Wiese]

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

Hi,

> Dangerous in case after performing installation, dynamic linked
> system becomes unusable: no logins are accepted, no shell can be
> spawned, even self-boot with init= kernel command line will give you
> nothing but a kernel panic. (Of course I should have a static linked
> busybox, but I even did not expected such a change will occur since
> 0.9.12)

Yes, a static busybox would might have helped there, but doing a libc
update on a running system should be avoided anyways even if it kind of
worked out before in your case as it seems!

> >I think the info about how you are building would be quite helpful.
> 
> I did installation as root user. I also do not run
> restrictive/hardened kernels. Sorry I lost log of installation, but
> after installing 0.9.15' libc.so "make install" refused to run with
> "Permission denied" error. Rest is simple: no command can be
> executed, login attempts refused, symptoms like "rm -fr /" was
> executed, only with "Permission denied". Only boot from rescue flash
> drive with prepared initrd showed that /lib/libc.so was
> half-installed with mode 600.
> 

see above answer.

Cheers,
Chris

-- 
PGP Fingerprint: F96B A15F DF25 2B3E 49CB BA16 241B F3E7 52FE AFC6

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: install.sh is wrong with libc.so

[Szabolcs Nagy]

* orc <orc@sibserver.ru> [2014-01-15 20:48:18 +0800]:
> 
> I agree with that. For historical reasons it's not. But I expected musl will continue to use standard install program.
> 

the standard install program is non-standard

and it happens to fail to solve the problem it was designed for:
atomic replacement of binaries so they can be used concurrently
during install without spurious failures

Re: install.sh is wrong with libc.so

[Rich Felker]

On Wed, Jan 15, 2014 at 08:48:18PM +0800, orc wrote:
> Szabolcs Nagy <nsz@port70.net> пишет:
> >* orc <orc@sibserver.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

Re: install.sh is wrong with libc.so

[orc]

Rich Felker <dalias@aerifal.cx> пишет:
>On Wed, Jan 15, 2014 at 08:48:18PM +0800, orc wrote:
>> Szabolcs Nagy <nsz@port70.net> пишет:
>> >* orc <orc@sibserver.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.
>

Thanks for detailed explanation and quick fix!

>Rich