Bug 161458 - Commands in /sbin and /usr/sbin not statically linked
Summary: Commands in /sbin and /usr/sbin not statically linked
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: distribution
Version: 4
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Bill Nottingham
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-06-23 15:44 UTC by Stuart MacDonald
Modified: 2014-03-17 02:54 UTC (History)
1 user (show)

(edit)
Clone Of:
(edit)
Last Closed: 2005-06-24 17:24:20 UTC


Attachments (Terms of Use)

Description Stuart MacDonald 2005-06-23 15:44:27 UTC
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 17:29:05 UTC
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 17:39:16 UTC
Thank you for reassigning to a more appropriate component.

Comment 3 Bill Nottingham 2005-06-24 17:24:20 UTC
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 19:13:49 UTC
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.