Bug 161458 - Commands in /sbin and /usr/sbin not statically linked
Commands in /sbin and /usr/sbin not statically linked
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
4
All Linux
medium Severity high
: ---
: ---
Assigned To: Bill Nottingham
Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-23 11:44 EDT by Stuart MacDonald
Modified: 2014-03-16 22:54 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-06-24 13:24:20 EDT
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 Stuart MacDonald 2005-06-23 11:44:27 EDT
Description of problem:

Not sure what the appropriate component is for this, feel free to reassign as
necessary.

The majority of commands in /sbin and /usr/sbin are *DYNAMICALLY LINKED*. This
makes it impossible to do anything useful when the shared libraries become
corrupt. As I found out this week. At the very least /sbin/init should be
statically linked. I couldn't even shutdown my machine.

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


How reproducible:

Every time.

Steps to Reproduce:
1. # ldd /sbin/*
2. Note that most commands are dynamically linked.
3.
  
Actual results:

Dynamically linked commands.

Expected results:

Statically linked commands.

Additional info:

As a test; delete your /lib/*.so* on a box you don't care about, then see what
you can do. Exactly nothing. Oh wait. You can handle your adsl connection,
because *those* commands are statically linked. Heaven forbid shutdown, reboot
or init be statically linked. Wouldn't want to be able to turn off a broken
system.
Comment 1 Alexandre Oliva 2005-06-23 13:29:05 EDT
Not sure why this got reported against libtool, it feels more like a distro-wide
thingie.  It would be better to file separate bugs against individual components
in violation of the rules, marking them as blocking this bug.
Comment 2 Stuart MacDonald 2005-06-23 13:39:16 EDT
Thank you for reassigning to a more appropriate component.
Comment 3 Bill Nottingham 2005-06-24 13:24:20 EDT
Static linking is generally discouraged:
 http://people.redhat.com/drepper/no_static_linking.html

Because of this, shipping things statically linked isn't really practical or
encouraged.

For system recovery purposes, things such as sln & busybox are shipped, as well
as rescue mode in the installer.
Comment 4 Stuart MacDonald 2005-06-24 15:13:49 EDT
Okay. I did not spot busybox in amongst the output of "echo /sbin/*". Busybox
satisfies my requirement for statically linked recovery apps.

That said, the person who authored the text at the URL above is completely
ignoring one reason to have statically linked apps, the reason I reported
this in the first place, STATICALLY LINKED APPS WORK WHEN YOUR SHARED
LIBRARIES HAVE BEEN CORRUPTED. DYNAMICALLY LINKED APPS DO NOT. This is not
a theoretical exercise, it's happened to me twice this week.

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