You might be right about the security. But for my purposes I would not be
syncing outside of my network. The SVN would only be accessibly from my lan
and when my laptop signs onto my network, it synchronizes. Sides, by your
argument just about any service is a security threat and should not be done,
unless ofc this setup presents a higher level risk. But most svn/cvs client
setups save their password it seems. You might be one of those that manually
types in the password everytime you sync - but it doesn't seem practical if
its your home computer. But lets play out your scenerio. If someone was to
exploit this they would have to gain access to the svn by either hacking
the server or hacking your computer the probability of these two happening
does not seem to increase or decrease if you were to use some autosyncing
mechanism and yet thats the first step to crumble this "svnfs". I do see
that the possible damage that could be done is increased, but I do not see
the probability increasing by anything significant. As for the "bot"
listening on the network - that was just a suggestion and could be replaced
by something that simply checks every 5 or 10 mins.
On 9/23/06, Neil Schneider <[EMAIL PROTECTED]> wrote:
Jason Kraus wrote:
> I might be overcomplicating things but in addition to syncing when you
> login, why not create some daemon that would get a signal from svn to
> synch. Basically when you commit from one machine, other machines
> currently online will be notified of the change and either notify the
> user or sync. If a computer is offline and then comes online, it will
> then sync. The other thing is have the same daemon listen for changes
> in a directory structure and commit changes automatically. I am a
> passively lazy person and I really don't feel like commiting every
> time i change something... if I have to speen 30 mins to code
> something that will save me 20 mins over a course of time, ill do it.
> I wonder if a project like this already exists. Like a snvfs? Just my
> 2 cents
>
Sounds like a botnet to me. :-) Seriously, the security implications
of this kind of setup are too risky to contemplate. It's ok for there
to be a public server that you "pull" from when logging in, and "push"
to when you logout. As long as you control your login, it's not a
violation of the network use policty and you also control the server.
What's not good is having code execute automatically from a public
server to worktations or servers on private networks, most behind
firewalls. It would essentially created a tunnel into the network.
A hacker will look for coding errors to exploit this connection. She
will hijack it using this exploit and now be able to operate from a
computer inside a private network, to attack that network. Since most
networks protected by firewalls are hard and crunchy on the outside
and soft and chewy on the inside, it will be a hackers delight.
This is the same reason most firewall experts would block GoToMyPC
from their list of network connections, to prevent this kind of
unauthorized tunnels. It's a principle of network security that you
don't allow code from outside your network, from sources you don't
control, unchecked and unsanitized, to execute inside your network.
This is why some people on this list turn off javascript in browsers,
and don't download many plugins for their browsers and refuse to view
content that uses certain plugins. The web server is sending code to
be executed on your computer, automatically.
All these things are allowed in a Windows world. In fact Microsoft
adds these "featrues" to "improve useablity". Any wonder their
platform is constantly and consistently compromised?
--
Neil Schneider pacneil_at_linuxgeek_dot_net
http://www.paccomp.com
Key fingerprint = 67F0 E493 FCC0 0A8C 769B 8209 32D7 1DB1 8460 C47D
"To announce that there must be no criticism of the president, or that
we are to stand by the president, right or wrong, is not only
unpatriotic and servile, but is morally treasonable to the American
public." [Theodore Roosevelt] 1918
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
