Bug 4155 - Improper handling of /../ in path names
Improper handling of /../ in path names
Status: ASSIGNED
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.23c
All Linux
: P3 normal
: none
Assigned To: Jeremy Allison
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-07 20:32 UTC by Peter Rabbitson
Modified: 2011-05-20 21:09 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Rabbitson 2006-10-07 20:32:37 UTC
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.
Comment 1 Jeremy Allison 2006-10-07 23:11:36 UTC
This is only in the config file - correct ? I'm pretty sure that this doesn't happen with pathnames given by remote clients.
Comment 2 Peter Rabbitson 2006-10-09 08:34:59 UTC
(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.
Comment 3 Spammer 2007-04-28 04:16:00 UTC
Created attachment 2498
Comment 4 Debian samba package maintainers (PUBLIC MAILING LIST) 2009-01-31 11:49:15 UTC
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
Comment 5 Jeremy Allison 2009-01-31 13:59:44 UTC
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.
Comment 6 Peter Rabbitson 2009-01-31 14:07:52 UTC
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.
Comment 7 Debian samba package maintainers (PUBLIC MAILING LIST) 2011-05-20 20:37:27 UTC
Just confirming that this bug is still present in 3.5.8
Comment 8 Jeremy Allison 2011-05-20 21:09:03 UTC
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.