* install.sh is wrong with libc.so @ 2014-01-15 8:42 orc 2014-01-15 11:01 ` Laurent Bercot ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: orc @ 2014-01-15 8:42 UTC (permalink / raw) To: musl 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: install.sh is wrong with libc.so 2014-01-15 8:42 install.sh is wrong with libc.so orc @ 2014-01-15 11:01 ` Laurent Bercot 2014-01-15 11:35 ` Christian Wiese 2014-01-15 12:13 ` Szabolcs Nagy 2 siblings, 0 replies; 10+ messages in thread From: Laurent Bercot @ 2014-01-15 11:01 UTC (permalink / raw) To: musl > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: install.sh is wrong with libc.so 2014-01-15 8:42 install.sh is wrong with libc.so orc 2014-01-15 11:01 ` Laurent Bercot @ 2014-01-15 11:35 ` Christian Wiese 2014-01-15 11:52 ` orc 2014-01-15 12:13 ` Szabolcs Nagy 2 siblings, 1 reply; 10+ messages in thread From: Christian Wiese @ 2014-01-15 11:35 UTC (permalink / raw) To: musl [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: install.sh is wrong with libc.so 2014-01-15 11:35 ` Christian Wiese @ 2014-01-15 11:52 ` orc 2014-01-15 12:58 ` Christian Wiese 0 siblings, 1 reply; 10+ messages in thread From: orc @ 2014-01-15 11:52 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: install.sh is wrong with libc.so 2014-01-15 11:52 ` orc @ 2014-01-15 12:58 ` Christian Wiese 0 siblings, 0 replies; 10+ messages in thread From: Christian Wiese @ 2014-01-15 12:58 UTC (permalink / raw) To: musl [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: install.sh is wrong with libc.so 2014-01-15 8:42 install.sh is wrong with libc.so orc 2014-01-15 11:01 ` Laurent Bercot 2014-01-15 11:35 ` Christian Wiese @ 2014-01-15 12:13 ` Szabolcs Nagy 2014-01-15 12:48 ` orc 2 siblings, 1 reply; 10+ messages in thread From: Szabolcs Nagy @ 2014-01-15 12:13 UTC (permalink / raw) To: musl * 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: install.sh is wrong with libc.so 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 0 siblings, 2 replies; 10+ messages in thread From: orc @ 2014-01-15 12:48 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: install.sh is wrong with libc.so 2014-01-15 12:48 ` orc @ 2014-01-15 14:18 ` Szabolcs Nagy 2014-01-15 16:31 ` Rich Felker 1 sibling, 0 replies; 10+ messages in thread From: Szabolcs Nagy @ 2014-01-15 14:18 UTC (permalink / raw) To: musl * 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: install.sh is wrong with libc.so 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 1 sibling, 1 reply; 10+ messages in thread From: Rich Felker @ 2014-01-15 16:31 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: install.sh is wrong with libc.so 2014-01-15 16:31 ` Rich Felker @ 2014-01-16 1:34 ` orc 0 siblings, 0 replies; 10+ messages in thread From: orc @ 2014-01-16 1:34 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-01-16 1:34 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-01-15 8:42 install.sh is wrong with libc.so orc 2014-01-15 11:01 ` Laurent Bercot 2014-01-15 11:35 ` Christian Wiese 2014-01-15 11:52 ` orc 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
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).