Samba improperly handles /../ in directory paths both when directly specified in the config file or obtained from a variable like %H. A string like 'TopDir/Subdir1/../Subdir2' will be converted to 'TopDirSubdir2' which is pretty far from what is desired. Was reproduced on three separate Debian systems (x86 and AMD64) running the latest version of Samba. Note: How did I come around this bug, and who would use /../ in a path specification anyway: vsftpd offers the nice trick of chrooting users to a part of their home directory path - it simply stops processing the string as soon as it sees '/./' So naturally all my users have homedirs like this: /home/webspace/<user>/./../../<user> where /home/webspace/<user> is world readable and /home/<user> is not. The abovementioned bug breaks the use of %H.
This is only in the config file - correct ? I'm pretty sure that this doesn't happen with pathnames given by remote clients.
(In reply to comment #1) > This is only in the config file - correct ? I'm pretty sure that this doesn't > happen with pathnames given by remote clients. > I am not really sure how to test for this... I mean a client can only request a location name, not a direct path, so I don't see how .. can be relevant in such a case.
Created attachment 2498
This bug is still here in 3.2 and, I would bet, in 3.3. It's fairly easy to reproduce: Set a share like this: [public] directory mask=0700 browseable=yes comment=Public read only=no create mask=0770 public=yes path=/var/tmp/foo/../samba-test The try to connect it: root@mykerinos:/var/tmp> smbclient //localhost/public -U bubulle Enter bubulle's password: Domain=[MYKERINOS] OS=[Unix] Server=[Samba 3.2.5] tree connect failed: NT_STATUS_BAD_NETWORK_NAME And the log shows: [2009/01/31 18:45:18, 0] smbd/service.c:make_connection_snum(1156) '/var/tmpsamba-test' does not exist or permission denied when connecting to [public] Error was Aucun fichier ou répertoire de ce type
This may be true and I'll look at it, but this is very low priority. I can't see what case would make you use /../ in a share path definition. Jeremy.
Re-posting from the 2nd part of the bug description: ------------------------------------------ Note: How did I come around this bug, and who would use /../ in a path specification anyway: vsftpd offers the nice trick of chrooting users to a part of their home directory path - it simply stops processing the string as soon as it sees '/./' So naturally all my users have homedirs like this: /home/webspace/<user>/./../../<user> where /home/webspace/<user> is world readable and /home/<user> is not. The abovementioned bug breaks the use of %H.
Just confirming that this bug is still present in 3.5.8
Sorry I can't see us fixing this. The problem is that /../ is invalid in a path from the client (and is very dangerous to boot, might allow the client to climb out of the share definition). We could call realpath() on the share pathname, but in order to do that we need to instantiate the share first and hard-fix the pathname without the /../. There's no way we will *ever* allow /../ in internally processed pathnames, it's just much too dangerous. Jeremy.