For some reason, Ubuntu installer won't let you choose password for
root user during the installation of the operating environment (OE). Then how do we run commands which need root privileges? The answer is simple: by using
sudo.
From what I read/understand, the user that we create during the installation of OE will have sudo privileges to run
root only commands. But I am pretty sure that it is inconvenient to prepend the string
sudo before all such commands. So, it is better to login as root user rather than the normal user, when a large number of "root only" commands/tools/utilities needs to be run. The first step is to set the password for the root user. Use the sudo privileges of the default user to run
passwd root
command. Enter the password string of the default normal user when it prompts for password with an useful hint:
enter your non-root user password. Type in the password chosen for the root user, when you are prompted to enter the new UNIX password with another useful hint:
enter new password for root. Re-type the chosen password one more time in the next step, and you are done.
% sudo passwd root
Password: (enter your non-root user password) <- default normal user's password
Enter new UNIX password: (enter new password for root) <- choose a password for the root user. It is different
from the one you typed in previous step -- and of course the default normal user's
password is not going to change after this step.
Retype new UNIX password: (re-enter new password for root)
passwd: password updated successfully
Perhaps the steps are the same for earlier versions of Ubuntu - but this is the very first time I have ever got my hands on Ubuntu distro.
_______________
Technorati tags:
Ubuntu |
Linux
Even though my blog entry
C/C++: global const variables, symbol collisions & symbolic scoping and article
Reducing Symbol Scope with Sun Studio C/C++ discuss about techniques to avoid symbol collisions in great length with examples, apparently they failed to provide a simple way to detect if the anomalous behavior is due to a symbol conflict. This blog entry tries to fill that gap with the help of Sun Studio debugger
dbx
and Solaris' link-edit tracing facility.
Let us start with the obligatory example first.
% cat dummy.c
#include <stdio.h>
void compare (int x, int y)
{
printf("\ndummy.c: compare(int, int)");
}
void Comparable (int a, int b)
{
printf("\nNext line should print \"dummy.c: compare(int, int)\". It you see something
else, it must be a symbol collision.");
compare (a, b);
}
% cc -G -o libdummy.so dummy.c
% cat thirdparty.c
#include <stdio.h>
int compare (char x, char y)
{
printf("\nthirdparty.c: compare(char, char)");
return (0);
}
% cc -G -o lib3rdparty.so thirdparty.c
% export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
% cat test.c
void Comparable(int, int);
int main()
{
Comparable(1, 2);
return (0);
}
% cc -o test -l3rdparty -ldummy test.c
% ./test
Next line should print "dummy.c: compare(int, int)". It you see something else, it must be a symbol collision.
thirdparty.c: compare(char, char)
1)
Using dbx
to detect symbol collision % dbx test
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.5' in your .dbxrc
Reading test
Reading ld.so.1
Reading lib3rdparty.so
Reading libdummy.so
Reading libc.so.1
(dbx) stop in compare
More than one identifier 'compare'.
Select one of the following:
0) Cancel
1) `lib3rdparty.so`compare
2) `libdummy.so`compare
a) All
> a
dbx: warning: 'compare' has no debugger info -- will trigger on first instruction
dbx: warning: 'compare' has no debugger info -- will trigger on first instruction
Will create handlers for all 2 hits
(2) stop in compare
(3) stop in compare
(dbx) run
Running: test
(process id 4404)
Next line should print "dummy.c: compare(int, int)". It you see something else, it must be a symbol collision.stopped in compare at 0xd27a0240
0xd27a0240: compare : pushl %ebp
(dbx) where
=>[1] compare(0x1, 0x2), at 0xd27a0240
[2] Comparable(0x1, 0x2), at 0xd27702d9
[3] main(0x1, 0x8047324, 0x804732c), at 0x80506f8
proc -map
shows the list of objects loaded with addresses.
(dbx) proc -map
Loadobject mappings for Process ID: 4404
0x08050000 /export/home/techno/C/test
0xd27a0000 /export/home/techno/C/lib3rdparty.so
0xd2770000 /export/home/techno/C/libdummy.so
0xd2690000 /lib/libc.so.1
0xd27c8000 /lib/ld.so.1 [LM_ID_LDSO]
From the above mappings, it appears that the symbol
compare
was bound to the definition in
lib3rdparty.so
. However it should really be bound to the definition in
libdummy.so
.
Other way to check the mappings is by getting the process id with
proc -pid
command, and using
pmap <pid>
command in
dbx
environment.
(dbx) proc -pid
4404
(dbx) pmap 4404
4404: /export/home/techno/C/test
08046000 8K rwx-- [ stack ]
08050000 4K r-x-- /export/home/techno/C/test
08060000 4K rwx-- /export/home/techno/C/test
D261E000 384K rw--- [ anon ]
D2680000 24K rwx-- [ anon ]
D2690000 764K r-x-- /lib/libc.so.1
D275F000 24K rw--- /lib/libc.so.1
D2765000 8K rw--- /lib/libc.so.1
D2770000 4K r-x-- /export/home/techno/C/libdummy.so
D2780000 4K rwx-- /export/home/techno/C/libdummy.so
D2790000 4K rwx-- [ anon ]
D27A0000 4K r-x-- /export/home/techno/C/lib3rdparty.so
D27B0000 4K rwx-- /export/home/techno/C/lib3rdparty.so
D27BA000 4K rwxs- [ anon ]
D27C8000 140K r-x-- /lib/ld.so.1
D27FB000 4K rwx-- /lib/ld.so.1
D27FC000 8K rwx-- /lib/ld.so.1
total 1396K
The following outputs in
dbx
env. confirm that the symbol
compare
was actually resolved in
lib3rdparty.so
rather than
libdummy.so
.
(dbx) which compare
`lib3rdparty.so`compare
which
command prints the full qualification of a given name.
(dbx) scopes
Function compare
File "(unknown OF)"
Loadobject /export/home/techno/C/lib3rdparty.so
The
scopes
command prints a list of active scopes.
(dbx) status
*(2) stop in compare
(3) stop in compare
The
status
prints the stop breakpoints in effect. In the above output we do not know which compare belong to which library.
-s
option of
status
will show the information we need.
(dbx) status -s
stop in `lib3rdparty.so`#compare
stop in `libdummy.so`#compare
2)
Using Solaris' link-edit tracing to detect symbol collisionSetting the run-time linker (
ld.so.1
) env variable
LD_DEBUG
to the token
bindings
causes the run-time linker to show the binding of a symbol reference to a symbol definition. Usually the output from run-time linker will be overwhelming if the application is big with a handful of symbols. By default, all this output will be displayed on stdout; so, it might be a little inconvenient to read all the output on stdout. However the tracing data from run-time linker can be redirected to a file using
LD_DEBUG_OUTPUT
env variable as shown below.
eg.,
% export LD_DEBUG=bindings
% export LD_DEBUG_OUTPUT=/tmp/bindings.log
% ./test
Next line should print "dummy.c: compare(int, int)". It you see something else, it must be a symbol collision.
thirdparty.c: compare(char, char)
% grep compare /tmp/bindings.log.0443*
/tmp/bindings.log.04436:04436: binding file=./libdummy.so to file=./lib3rdparty.so: symbol `compare'
Observe that the call to symbol (function or method)
compare
in
libdummy.so
was resolved in
lib3rdparty.so
. It confirms the symbol conflict. This problem arises when the symbols are left in default global scope. Use
elfdump
tool to check the scope and attribute of the symbol of interest (
compare
in this example).
% /usr/ccs/bin/elfdump -sN.symtab libdummy.so | grep compare
[40] 0x00000280 0x00000027 FUNC GLOB D 0 .text compare
% /usr/ccs/bin/elfdump -sN.symtab lib3rdparty.so | grep compare
[41] 0x00000240 0x00000036 FUNC GLOB D 0 .text compare
Symbols with global default scope are always vulnerable to symbol conflicts, as seen in the above example. The primary reason being any one can interpose upon these global default symbols. To prevent others from interposing on the symbols that are completely useless outside the defining component (executables or shared objects), make them
protected with Sun Studio's
-xldscope=symbolic
compiler option or
__symbolic
attribute. Note that these language extensions were introduced in Sun Studio 8. Refer to
Reducing Symbol Scope with Sun Studio C/C++ article for detailed information about global, symbolic scopes and also about the linker scoping language extension. If you are using any older compiler, use
-Bsymbolic
linker option to build your executables and shared libraries there by making the symbols protected.
eg.,
% cc -G -o libdummy.so -xldscope=symbolic dummy.c
% /usr/ccs/bin/elfdump -sN.symtab libdummy.so | grep compare
[40] 0x00000280 0x00000027 FUNC GLOB P 0 .text compare
% cc -G -o lib3rdparty.so -xldscope=symbolic thirdparty.c
% /usr/ccs/bin/elfdump -sN.symtab lib3rdparty.so | grep compare
[41] 0x00000240 0x00000036 FUNC GLOB P 0 .text compare
% cc -o test -l3rdparty -ldummy test.c
% ./test
Next line should print "dummy.c: compare(int, int)". It you see something else, it must be a symbol collision.
dummy.c: compare(int, int)
Note that the compiler option
-xldscope=symbolic
and the linker option
-Bsymbolic
make all the symbols protected - so, it is not possible for others to interpose upon the symbols of such libraries or executables. For some reason if you have to leave some symbols in global default scope, use
__symbolic
specifier for those symbols which must be protected from interposers.
eg.,
% cat dummy.c
#include <stdio.h>
__symbolic void compare (int x, int y)
{
printf("\ndummy.c: compare(int, int)");
}
void Comparable (int a, int b)
{
printf("\nNext line should print \"dummy.c: compare(int, int)\". It you see something
else, it must be a symbol collision.");
compare (a, b);
}
% cc -G -o libdummy_.so dummy.c
% /usr/ccs/bin/elfdump -sN.symtab libdummy_.so | grep -i compar
[40] 0x00000280 0x00000027 FUNC GLOB P 0 .text compare
[45] 0x000002b0 0x00000037 FUNC GLOB D 0 .text Comparable
Observe that the symbol
compare
is protected (although global in scope); and hence cannot be overridden by another global symbol with name
compare
. However
Comparable
can still be overridden by a different implementation, due to its global default scope.
Just to make sure that the symbol was bound to the definition in the right library, you can check the mappings, scope etc., again with
dbx
. Link-edit tracing won't show any binding information when it gets resolved within the same library.
_______________
Technorati tags:
Sun Studio |
Solaris |
linker |
Programming