On Wed, 19 Dec 2007, Michael Halcrow wrote:
-> > The test with one file on this machine was OK, but soon as I put it
-> > into real use on another machine and tried to do a mount, the mount
-> > fails on empty directories. It says something about not being able
-> > to resolve a full path, but there's nothing special about the
-> > directory /var/cache/ecryptfs/100. It's not NFS or any such thing,
-> > just a normal filesystem directory. This was reproduced with first
-> > my real key, then here, a testing key.
->
-> Strange. So if you execute just this as root, you get an error?
->
-> ---
-> #include <limits.h>
-> #include <stdlib.h>
-> #include <errno.h>
-> #include <stdio.h>
->
-> int main()
-> {
-> char *path;
->
-> path = realpath("/var/cache/ecryptfs/100", NULL);
-> if (path == NULL)
-> printf("errno = [%m]\n", errno);
-> }
This one had me confused.
vdrl.ath.cx:
gcc -o test_path test_path.c && ./test_path
errno = [Invalid argument]
Filesystem Mount Megs Used Avail %Used fs Type
/dev/hda1 / 36784.6 13783.8 21102.1 43% ext2
configfs /config 0.0 0.0 0.0 0% configfs
devpts /dev/pts 0.0 0.0 0.0 0% devpts
shm /dev/shm 248.0 0.0 248.0 0% tmpfs
proc /proc 0.0 0.0 0.0 0% proc
usbfs /proc/bus/usb 0.0 0.0 0.0 0% usbfs
sysfs /sys 0.0 0.0 0.0 0% sysfs
securityfs /sys/kernel/sec 0.0 0.0 0.0 0% securityfs
atr2.ath.cx:
gcc -o test_path test_path.c && ./test_path
-8- [EMAIL PROTECTED] ~ #
Filesystem Mount Megs Used Avail %Used fs Type
/dev/hdc1 / 74839.1 10156.2 60881.2 19% ext2
configfs /config 0.0 0.0 0.0 0% configfs
devpts /dev/pts 0.0 0.0 0.0 0% devpts
shm /dev/shm 77.8 0.0 77.8 0% tmpfs
/dev/hdd3 /home 2721.6 74.7 2508.6 8% ext2
proc /proc 0.0 0.0 0.0 0% proc
usbfs /proc/bus/usb 0.0 0.0 0.0 0% usbfs
sysfs /sys 0.0 0.0 0.0 0% sysfs
securityfs /sys/kernel/sec 0.0 0.0 0.0 0%
securityfs
/dev/hdd2 /tmp 178.7 12.1 157.1 12% ext2
/dev/hdd1 /var/tmp 134.1 0.0 126.9 5% ext2
Two different results both on an ext2 filesystem, depending on
the machine. It's not just that directory, but I tried the
program on each directory all the way down to / and got the
same result each time.
Worst of all, I get two different results on two machines that
are supposedly equal, only difference being one is a Pentium II
and the other's a Pentium 4. I couldn't see why this was, then
something made me think of ld.so.preload. The load on atr2 is
too high to use any extra time to run everything thru /lib/libsafe.so.2,
so on that machine there is no /etc/ld.so.preload, and hence no
/lib/libsafe.so.2. On vdrl, the load is lower and /lib/libsafe.so.2
was left in. Strangeness, I've never seen it affect anything before
in such a way:
[EMAIL PROTECTED] /tmp # whoami && uname -a && cat /etc/ld.so.preload && gcc -o
test_path test_path.c && ./test_path
root
Linux vdrl 2.6.23.9 #1 Sat Dec 15 05:08:22 EST 2007 i686 GNU/Linux
/lib/libsafe.so.2
errno = [Invalid argument]
-27- [EMAIL PROTECTED] /tmp # mv /etc/ld.so.preload /var/tmp
`/etc/ld.so.preload' -> `/var/tmp/ld.so.preload'
[EMAIL PROTECTED] /tmp # ./test_path
-8- [EMAIL PROTECTED] /tmp #
----------------------------------------------------
[EMAIL PROTECTED] ~ # ls -la /lib/libsafe.so.2
lrwxrwxrwx 1 root root 17 2005-11-20 12:00 /lib/libsafe.so.2 ->
libsafe.so.2.0.16*
[EMAIL PROTECTED] ~ # echo /lib/libsafe.so.2 > /etc/ld.so.preload
[EMAIL PROTECTED] ~ # gcc -o test_path test_path.c && ./test_path
errno = [Invalid argument]
-27- [EMAIL PROTECTED] ~ # rm /etc/ld.so.preload
[EMAIL PROTECTED] ~ # ./test_path
-8- [EMAIL PROTECTED] ~ #
realpath is one of the functions watched by libsafe due to the possibility of
overflowing the path buffer. Evidently it changes something, somewhere, yet no
record is made in the syslog, as usually happens when libsafe makes an action.
As you can see from above, the file is dated in 2005. I checked from their
website but I couldn't find anything about libsafe anymore. My guess is it's
discontinued.
I guess the moral of the story is don't use /etc/ld.so.preload ;)
My fault, but at least now it's known, and on the mailing list too, if someone
else should have a similar problem, to look at what's preloaded by the dynamic
linker. At one time some distros used libsafe, but it's old(er) now and
possibly discontinued. It did find some bugs in tcsh and others, but never to
my knowlege stopped any real attacks (never had any of this type so far as I
can tell). I can do without it, or use libssp from gcc for similar
functionality, which is being maintained at the moment. Thanks for looking
into this.
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
eCryptfs-users mailing list
eCryptfs-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecryptfs-users
