File permissions of .torchat and its contents seem wrong.

[GoogleCodeExporter]

I think when creating directories like .torchat, the mode parameter should be 
passed to os.mkdir().

os.mkdir(dir, 0700)

The tor.sh file is completely unprotected. With the standard file permissions 
for users' home directories and standard umask value 0022, any user on the 
system can edit ~user/.torchat/Tor/tor.sh.

Original issue reported on code.google.com by schecko...@gmail.com on 14 Jan 2011 at 6:54

[GoogleCodeExporter]

Are you sure? On my system it is 
drwxr-xr-x   3 bernd bernd    4096 2011-06-19 19:03 .torchat
so no other user can write. 

Also shouldn't this generally be protected by the fact that it is inside the 
user's home folder and then automatically maximally allow what is allowed by 
this folder? 

I'm going to make the .torchat folder 0700 in the next release, just in case 
the home folder allows too much access, this should then take away all access 
from all other users for everything contained within ~/.torchat, shouldn't it?

Original comment by prof7...@gmail.com on 10 Nov 2011 at 6:09

[GoogleCodeExporter]

Yes, those are the permissions for .torchat. So anyone can read the contents of 
.torchat.

.torchat:
total 8
drwxr-xr-x 6 steve staff  204 Nov 10 10:21 Tor
-rw-r--r-- 1 steve staff   90 Jan 13  2011 buddy-list.txt
-rw-r--r-- 1 steve staff 1000 Jan 15  2011 torchat.ini

.torchat/Tor:
total 8
drwx------ 4 steve staff  136 Jan 15  2011 hidden_service
-rwxrwxrwx 1 steve staff   87 Jan 13  2011 tor.sh
drwx------ 8 steve staff  272 Jan 18  2011 tor_data
-rw-rw-rw- 1 steve staff 1903 Jan 13  2011 torrc.txt

.torchat/Tor/hidden_service:
total 8
-rw------- 1 steve staff  23 Jan 15  2011 hostname
-rw------- 1 steve staff 887 Jan 13  2011 private_key

.torchat/Tor/tor_data:
total 6032
-rw------- 1 steve staff   15064 Jan 13  2011 cached-certs
-rw------- 1 steve staff  526549 Jan 18  2011 cached-consensus
-rw------- 1 steve staff 4181021 Jan 18  2011 cached-descriptors
-rw------- 1 steve staff 1432341 Jan 18  2011 cached-descriptors.new
-rw------- 1 steve staff       0 Jan 15  2011 lock
-rw------- 1 steve staff   13691 Jan 18  2011 state

So anyone can read my buddy list and anyone can write my tor.sh and torrc.txt.

This is not terribly surprising since if you look at the source zipfile (which 
doesn't contain a top level directory!), src/Tor/tor.sh and src/Tor/torrc.txt 
are read-write by all and these get copied to ~/.torchat/Tor:

    if not os.path.exists(data_dir):
        os.mkdir(data_dir)

    #and create the folder 'Tor' with tor.exe and torrc.txt in it if necessary
    data_dir_tor = os.path.join(data_dir, "Tor")
    if not os.path.exists(data_dir_tor):
        os.mkdir(data_dir_tor)
        if isWindows():
            tor_exe =  "tor.exe"
        else:
            tor_exe = "tor.sh"
        shutil.copy(os.path.join("Tor", tor_exe), data_dir_tor)
        shutil.copy(os.path.join("Tor", "torrc.txt"), data_dir_tor)

I don't see what protection being inside the home directory confers. These are 
frequently read/execute by all.

Original comment by schecko...@gmail.com on 10 Nov 2011 at 6:40

[GoogleCodeExporter]

when the home folder itself has no permissions for other users then others 
should not be able to write *any* file within it or within any of its 
subfolders, no matter what modes these files have set. At least this is how my 
linux box here behaves, I have just verified it by trying to read a chmod 0777 
file from a different user. the user's home directory is 0700 and I cannot read 
or write anything inside this user's home.

I have now commited a patch to automatically chmod ./torchat and ./torchat/Tor 
and also tor.sh after creation (and on every start and also always replaces 
tor.sh with a fresh copy of that file which is needed anyways since there 
recently was a bugfix to that file).

Unless I am totally wrong (I am not always right) and it is behaving 
differently from what I understand and what I am observing here then it would 
have been already sufficient to only chmod 0700 .torchat which would then 
completely protect all files within it, no matter what modes these files have 
set.

Original comment by prof7...@gmail.com on 10 Nov 2011 at 7:06

[GoogleCodeExporter]

ok, it seems I was wrong, linux really does not respect the permissions of the 
containing folder when accessing a file. This is quite counterintuitive and 
bizarre (and dangerous). I'm now chmodding all files individually.

Original comment by prof7...@gmail.com on 10 Nov 2011 at 8:30

[GoogleCodeExporter]

please install 0.9.9.550 and after running it (or after installing and running 
it for the first time) check if there are still files created with wrong 
permissions.

Original comment by prof7...@gmail.com on 11 Nov 2011 at 2:47

• Changed state: Started