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, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
