Friday, September 02, 2005

Managing Library Paths with crle

Managing Library Paths with crle

To begin with, crle stands for "configure runtime linking
environment". It is a command that allows Solaris sysadmins to better
manage their dynamic linker. Specifically, it allows you to configure
library paths so that programs run on a system will have as easy
access to shared library files in locations like /usr/local/lib or
/opt/lib as they do to /usr/lib. Instead of configuring a
LD_LIBRARY_PATH to give these lib directories visibility, you run the
crle command and augment the load library path on a system-wide basis.
In other words, the crle command is basically the equivalent of
updating ld.config.

What's Configured Now?

To view the system library path on a Solaris system, you can issue the
crle command on a line by itself:

# crle

Default configuration file (/var/ld/ld.config) not found Default
Library Path (ELF): /usr/lib (system default) Trusted Directories
(ELF): /usr/lib/secure (system default)

Notice that, in the absence of an ld.config file, a limited library
search path is established containing only /usr/lib for normal usage.

This library path setting is independent of any paths you may have
added to your LD_LIBRARY_PATH interactively or through settings in
your dot files. The paths shown are the paths that binaries on your
system will use regardless of the LD_LIBRARY_PATH setting.

How to Configure New Paths

To add a new path to your dynamic linker, you would use the crle -l
command, but this command overwrites the existing path. In other
words, you need to repeat the existing path elements so as not to
remove them. For example, you might type the following command to add
/usr/local/lib to what is shown above:

# crle -l /usr/lib:/usr/local/lib

Afterwards, you should verify the new settings:

# crle

Configuration file [2]: /var/ld/ld.config
Default Library Path (ELF): /usr/lib:/usr/local/lib Trusted
Directories (ELF): /usr/lib/secure (system default)

Command line:
crle -c /var/ld/ld.config -l /usr/lib:/usr/local/lib

What should you do if You Break It?

If you type your crle command carefully, you should have an easy time
augmenting your dynamic loader's search path. If, on the other hand,
you break the path -- for example, by typing crle -l followed only by
the paths you intend to add -- you can send your Solaris system into a
very troublesome state. The reason is simple; just about every command
that you type on your Unix system depends on shared object files
stored in /usr/lib -- including commands as benign as ls. So, if
/usr/lib disappears from your linker's search path, your ability to
work wonders on the command line will come to an abrupt end -- at
least until you type the command again. The breakage will be
illustrated with errors such as this:

$ ls ls: fatal: open failed: No such file or directory Killed

Normal Unix command functionality can be restored by typing a second
crle command. While you could also fix the problem for yourself by
setting your LD_LIBRARY_PATH as shown below, this wouldn't help anyone
else who logs into the system.

LD_LIBRARY_PATH=/lib:/usr/lib;export LD_LIBRARY_PATH

Typing the crle command with the complete library path should fix the
problem immediately and easily -- except when you can't issue it.

What should you do if You Break It with sudo?

A second crle won't help you out of the pit that you inadvertently
created if your super powers are bequeathed through sudo. In this
case, you won't be able to reproduce the linker's path with a "sudo
crle" command because sudo itself depends on /usr/lib.

$ sudo crle -l /lib:/usr/lib:/usr/local/lib sudo: fatal: open failed: No such file or directory Killed

In fact, remote access to the box will also fail because telnet, ftp
and ssh will try to access shared libraries which are no longer in the

$ telnet boson
Trying Connected to Escape
character is '^]'. in.telnetd: fatal: open
failed: No such file or directory Connection closed by foreign host.

And, while you can restore the functionality of many commands by
setting your LD_LIBRARY_PATH, this won't restore remote access -- and
it won't restore your sudo privileges because sudo, for fairly obvious
security reasons, doesn't pay attention to this environment variable.

While you can appeal to a higher authority (the guy who can exercise
superuser privilege without using sudo), there's also a workaround
that you can use to regain your superuser access without having to
wait for someone with the root password to come to your rescue.

The trick here is to use the LD_NOCONFIG environment variable to some
(any) value, thus causing the runtime linker to ignore configuration
files. This returns your operational library path to the default
/usr/lib, thus allowing your sudo command to perform the repair of the
hosed library path.

bash$ LD_NOCONFIG=true;export LD_NOCONFIG
bash$ sudo crle -l /lib:/usr/lib:/usr/local/lib Password:

Where Did crle Come From?

The crle command had existed in Solaris since Solaris 7, but it most
familiar to systems administrators who need to augment library paths
when installing applications that install libraries in non-system
locations such as /usr/local/lib or /opt/lib. Since it established
system-wide library paths, it is recommended over LD_LIBRARY_PATH


Post a Comment

<< Home