problems with latest smbfs changes on 2.4.34 and security backports

[Santiago Garcia Mantinan <manty@debian.org>]

Hi!

I have discovered a problem with the changes applied to smbfs in 2.4.34 and
in the security backports like last Debian's 2.4 kernel update these changes
seem to be made to solve CVE-2006-5871 and they have broken symbolic links
and changed the way that special files (like devices) are seen.

For example:
Before: symbolic links were seen as that, symbolic links an thus if you tried
to open the file the link was followed and you ended up reading the
destination file
Now: symbolic links are seen as normal files (at least with a ls) but their
length (N) is the length of the symbolic link, if you read it, you'll get the
first N characters of the destination file. For example, on my filesystem
bin/sh is a symlink to bash, thus it is 4 bytes long, if I to a cat bin/sh I
get ELF (this is, the first 4 characters of the bash program, first one
being a DEL).

Another example:
Before: if you did a ls of a device file, like dev/zero you could see it as
a device, if you tried opening it, it wouldn't work, but if you did a cp -a
of that file to a local filesystem the result was a working zero device.
Now: the devices are seen as normal files with a length of 0 bytes.

Seems to me like a mask is erasing some mode bits that shouldn't be erased.

I have carried my tests on a Debian Sarge machine always mounting the share
using: smbmount //server/share /mnt without any other options. The tests
were carried on a unpatched 2.4.34 comparing it to 2.4.33 and also on
Debian's 2.4.27 comparing 2.4.27-10sarge4 vs -10sarge5. The server is a
samba 3.0.23d and I have experienced the same behaviour with samba's
unix extensions = yes and unix extensions = no.

I don't know what else to add, if you need any more info or want me to do
any tests just ask for it.

Regards...
-- 
Santiago García Mantiñán
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/