aaronmk
-
Posts
8 -
Joined
-
Last visited
-
Days Won
1
aaronmk's Achievements
New User (1/3)
-
That must be new in 1.2, which was released on 2013-11-5, after I submitted the bug.
-
Is this a new feature? I don't think it prompted for a password back when I submitted the bug, but maybe that has changed since then?
-
But wouldn't NAS users want their data protected, too? This would suggest that requiring the user to set a password (and warning them that their data will be wide open otherwise) is the best solution.
-
Javascript doesn't support filesystem-level security because it's browser-based. You would instead have to modify the btsync program itself (i.e. the server-side code) to support things like chroot. Modifying btsync to fix security problems would of course require the source code, which BitTorrent hasn't made public (yet?).
-
That works as long as you are the only one with access to your computer. If btsync is running on a shared computer, any other user on the computer would also be able to access it. (Other users would also notice that someone else was already running the WebUI on port 8888.) I think ideally, the default mode for btsync would just prompt for a password to use with the WebUI, and generate (and reuse) a default config file stored in user's home directory.
-
It will actually show previously-added shared folders when you restart btsync. The /tmp/SyncApp_dumps/ directory is empty, though, so I'm not sure where it stores the configuration. Maybe in the BitTorrent Sync tracker itself?
-
I think users will generally run btsync with no arguments to test out the command, not realizing that they are starting the WebUI daemon. Could we make btsync display the help message when run without arguments?
-
Running btsync on Linux will by default create a *publicly-accessible, unprotected* WebUI, allowing anyone on the web to create a sync folder to view and edit files your files (i.e. files in directories writable by you). Could the defaults (used when running btsync without a config file) be changed to prevent this unintended data leak? A temporary workaround is to run `killall btsync` to turn off the WebUI, and then use --config with a config file that sets webui > password to a secure password. You can use `lsof -i` to verify that the WebUI is not running.