From: orc <orc@sibserver.ru>
To: musl@lists.openwall.com
Subject: Re: install.sh is wrong with libc.so
Date: Wed, 15 Jan 2014 19:52:19 +0800 [thread overview]
Message-ID: <da7baff3-ca15-4883-9e71-6aaa3bd2f20b@email.android.com> (raw)
In-Reply-To: <20140115123552.39250038@mopad>
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
next prev parent reply other threads:[~2014-01-15 11:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-15 8:42 orc
2014-01-15 11:01 ` Laurent Bercot
2014-01-15 11:35 ` Christian Wiese
2014-01-15 11:52 ` orc [this message]
2014-01-15 12:58 ` Christian Wiese
2014-01-15 12:13 ` Szabolcs Nagy
2014-01-15 12:48 ` orc
2014-01-15 14:18 ` Szabolcs Nagy
2014-01-15 16:31 ` Rich Felker
2014-01-16 1:34 ` orc
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=da7baff3-ca15-4883-9e71-6aaa3bd2f20b@email.android.com \
--to=orc@sibserver.ru \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).