Bug 214375 - Kernel panic when libc.so.6 be overwrited
Kernel panic when libc.so.6 be overwrited
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: glibc (Show other bugs)
4.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-07 05:24 EST by Brian Chung
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-07 09:36:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Brian Chung 2006-11-07 05:24:38 EST
Description of problem:

we use ibm tsm solution to backup linux host, kernel panic when libc-2.3.4.so be
restored by tsm agent. even i recover it with a backup file from localhost.


Version-Release number of selected component (if applicable):

glibc-2.3.4-2.25

How reproducible:


Steps to Reproduce:

1.cd /lib/tls/
2.cp libc-2.3.4.so libc-2.3.4.so.bak
3.cp libc-2.3.4.so.bak libc-2.3.4.so
  
Actual results:

kernel panic: reboot
show the following messages:
/sbin/init :error while loading share libraries: /lib/tls/libc.so.6: file too
short kernel panic - not syncing: Attemped to kill init !

Expected results:


Additional info:
Comment 1 Jakub Jelinek 2006-11-07 09:36:29 EST
That's user error.  You really can't restore libc.so (or any other widely used
shared library or the dynamic linker) using cp on a running system.
cp overwrites the target file (opens it with O_WRONLY|O_TRUNC) and at that point
any program that have the current libc.so.6 mapped can crash.  If init crashes,
the whole system is dead of course, the root just shot himself in the foot.
The way shared libraries should be restored is that they are copied to a
temporary file in the same directory where they should be installed to and
once copied there, they are moved or linked over the target file (mv -f or ln
-f).  install(1) gets close, it unlinks the target file and then copies it over,
but there is still a window in which the old libc doesn't exist and new one
doesn't either, so e.g. newly started programs in that timeframe could die.
rpm does the right thing AFAIK.

Note You need to log in before you can comment on or make changes to this bug.