LazyWolf
-
Posts
40 -
Joined
-
Last visited
Posts posted by LazyWolf
-
-
Personaly I see no reason to develop anything with the BTSync API until this issue is resolved. I think the API key creation should be on each btsync, to allow the users to make their own keys and allow access to their btsync instances. At any point in time my hours/weeks of work could just be shut off by a Bittorrent employee which is completly against the idea of P2P. It would be like trying to build a house of cards in a vehical traveling down a dirt road -- you never know when the whole thing will be taken away from you.
-
I do not see the current method of having Bittorrent deciding if a client is able to talk to someone's private server working out very well.
What would be the point of developing something for BTSync using the API if at any moment someone from Bittorrent could decide to remove your access to the product and end hours, days, months of work.
The only real use I can see for a project like this is for the api beta, once the api is out of beta I think Bittorrent as the gatekeeper should be removed.
I would love to still have api keys but I think it should be up to every individual server running BTSync to generate api keys for clients to connect to it...
Having Bittorrent have to approve any api use by clients or users in the future make the project useless in my mind. I see it like having strong encryption but every time you want to use it you have to ask for permission from twenty people, fill out a form, and wait 30+ days for possible approval.
One posible abuse I could see steaming from Bittorrent control over the api keys would be something like charging developers per Gig of data transfered because of the use of their program, if one does not pay up they could just disable your access.
I am hoping that the current situation is temporary.
In the future I am looking forward to our own api key generation with acls for every key we create with no intervention or interaction with Bittorrent.
-
When I have free time I will continue to work on my Python lib...
-
You shouldn't need to open any ports in order for it to sync, but you can check the to see what ports are being blocked by using
dmesg
-
1. Can your ubuntu server connect to the internet?
ping 8.8.8.8
2. Can you access btsync from your local network?
Also you say you do not want the website to be reachable from the internet, why did you forwardport 8888? You do not need to forward the webui port for sync to work.
-
If you have it set to 127.0.0.1 you can only access btsync from your local computer as you are setting it to listen on a virtual interface that exists only within that device.
0.0.0.0 listens on all devices eth0, wlan0, etc.
-
0.0.0.0:port to listen on then add a firewall rule...
sudo ufw allow from 192.168.1.0/24 to any port webuiport proto tcp -
To be fair: Encfs has the same problem
Encfs is not build with Plausible Deniability in mind, encfs is easy to detect because of its .encfs6.xml file format. Where if you were to compare a TC volume that wasn't made with --quick and a file of the same size made from
dd if=/dev/urandom of=randFile.dd
you would be unable to tell which if either of them were TC volumes.
-
ok, but knowing where the data is, doesn't make the decryption any easier at all i believe?
True but knowing how much data has changed from a forensics point of view can give you quite a bit of information...
Say a person went to TPB and searched non https, found a movie that was 752227840 bytes. They download said movie and move it to their encrypted tc volume which is later synced across a network.
If someone was watching and had control of the backup computer they would not be able to access the data but if they also had access to your net history (LEO) they would be able to show you searched on TPB and one of the links you went to had a 752227840 byte movie then an hour later the person moves the movie to the tc volume and it slowly syncs only the new data 752227840 bytes added to the filesystem. They now can show that the person more than likely moved an illegally downloaded movie from their main partition to an encrytped one.
Also if using a hidden volume an adversary would be able to see that you are writing data to one part of the volume that the normal outter volume password will not have access to. Then they could "prove" there was a hidden volume and you lose the Plausible Deniability TC gives.
-
I think that syncing a TC volume would defeate one of TrueCrypts core security features. You know when you have to wait a long time when creating a new volume or encrypted partition in TC, it is filling that space with "random" data. This makes it hard to guess where data is located(if any at all) in the space. One of the ways BTSync deals with large files is to split up the file into chunks of 4MB to see if it needs to be updated if an attacker could watch the data from a TC volume being backed up to a service like backupsy they would be able to eliminate a large section of the volume and know exactly where the real data is located.
-
It is to be expected, that process is forked to the background which means it is not tied to your session.
You should be able to run it with the extra --nodaemon option in a ~/.config/autostart/something.desktop file I think that would spawn it tied to the current session.
-
If you want to use the web ui you can not have a share in the config file. The web UI stores secrets in a seperate file, so generate a new config file and only edit device_name, login, and password. Do not change secret or dir.
-
One thing I would recommend would to use AppArmor to harden the btsync process a bit.
-
It should run as the current user, but you could do a test my making a new folder and chmod 777 it, then add it to btsync and let btsync add some files from another device. Then you go into the folder through a terminal and type ls -alh .
This will show you the information on all the files/folders, username and groups of all the files.
-
The mac version should be running as the current user.
-
I am currently running .70 and I just did exactly what you mentioned -- adding a file then deleting it on the server side -- and I am seeing the same thing as you with. The server I am using is Ubuntu server 13.04 and the desktop is 13.04 Desktop.
In the linux web gui for the desktop I see the desktop knows the server does not have all the files because it shows 1.2M (Up), but on the server it shows "Synced on..." so it seems if you delete a file from a read-only share it will not be re-synced.
My test...
[Desktop] -> Ubuntu desktop 13.04 64-bit
[backup Server] -> Ubuntu server 13.04 64-bit
---
[Desktop] has full access to a folder with 3G+ of pictures {Share A - Full}
[backup Server] uses btsync to sync {Share A} to a local folder
---
Using ssh I logged into [backup Server] and deleted a file in {Share A - Read Only}
BTsync has yet to re-add the file
It would be nice to see this fixed.
-
I would recommend that you still keep up to date with your tape backups, just in case there is a unforeseen error with btsync right when you need the data.
It can never hurt to have more backups.
-
It may help us to know which versions your test machines are running(also are they all running the same version)...
Also BTSync is in beta... So it may not be the best idea to make it an "integral" part of your backup infrastructure just yet as it may fail or do damage to your files.
-
My understanding is that the syno repo is not one supported or updated by the btsync people, I think it is maintained by a syno member -- I could be wrong -- but I think it would be unfair to blame the underdocumentation of the syno btsync module on the btsync people that have little to nothing to do with it.
Again I am not well read on how the syno works but in a tipical linux environment you have the normal permissions (rwxrwxrwx = 777) those work based on user:group:other. So if the syno creates a physical group when you add a group through their GUI you could use
$ chgrp groupName /path/to/share -R
$ chmod o-rwx /path/to/share
the chgrp should change the ownership of your shared folder -- and every file/folder within that folder -- to the group you want and the chmod will remove the read, write, and execute perms for others, so if you had (rwxrwxrwx = 777) it would now be (rwxrwx--- = 770). This would mean the user that owns the folder and the group that owns the folder would have full access to that folder.
Another method would be to use ACLs, which I am not sure if your syno would support.
$ setfacl group:newGroup:rwx /path/to/share
$ setfacl -d group:newGroup:rwx /path/to/share
-
I will start off with saying that you do not need to change any perms on your mac, your mac is running btsync just fine. It is solely an issue with your syno -- permissions are not synced through btsync so if you change the permissions of a file on one computer it does not change them anywhere else but that one device.
When it comes to the syno I am not exactly sure as I do not own a syno pretty much all I can tell you is you can stop messing with your mac and other device because it is solely an issue with your syno.
Maybe someone else here will be able to help you with the syno issue, but you may want to try a syno community forum.
-
It could be that a file or folder inside the syno share folder is having an issue...
You could try this to look for non rwxrwx perms for directories...
find /path/to/share -type d -not -perm 777 -exec ls -alh {} \;and this for files, not sure if this work as the find command I am use to is the newest version...
find /path/to/share -type f -not -perm 666 -exec ls -alh {} \;These commands should show you all the files and folders that do not have the expected perms as well as show you their names it should give you owner:group and the current set of perms.
If that is found to be the issue you will need to look into acls for the folders.
-
What I am saying is it seems the syno is having a permission error.
Mac[able to add files] -> Syno[unable to download/doesnt have perms]
Syno[unable to write to folder] -> Mac[desn't get anything from the syno]
So login to the syno and chmod 777 the folder btsync is using. or make sure the user that is running btsync on the syno owns the folder you are trying to add files to. If btsync on the syno can not write to the folder it will fail.
What you have described -- to me at least -- seems to be an issue on the Syno and nothing to do with your mac.
-
Im a linux person so...
killall btsyncshould kill btsync, it will have to be entered in the terminal though.
-
...
However now, sync do not occur anymore and in the btsyn gui of the syno it says "don't have permission to write in selected folder" and this for all the synced folders.
I check in Mac os what were the permission for the folder and it is in read and write for everyone in the gui (which should mean chmod 777)
If the syno gui was the btsync instance that said it could not write, wouldn't that mean there was a permission issue on the syno and not your mac?
Plans for the API key?
in Developers
Posted
From my experience it would be extremely simple to load the executable up in olly and bypass any checks that are built in, then just distribute that with my application. These limitations only restrict legitimate developers and make building any thing using btsync a waste of time and energy.
Sent from my SCH-I545 using Tapatalk