On 9/23/06, Stewart Stremler <[EMAIL PROTECTED]> wrote:

begin  quoting Jason Kraus as of Sat, Sep 23, 2006 at 05:27:01PM -0700:
[snip]
> On 9/23/06, Stewart Stremler <[EMAIL PROTECTED]> wrote:
[snip]
> >And reliability. If you screw up on one machine, all your machines are
> >going to be screwed up.
>
> Thats what revision control is for. If you screw up, you roll it back.
This
> is mainly why i would like a svn fs. Even if none of my computers leave
the
> network, it is nice to roll back documents.

You'd need an alternate account so that you could check out the
other account's configuration to roll it back.

[snip]
> >Whenever "automatically" enters a conversation regarding computers,
> >the little "check security implications" light should turn on.
>
> Im a bit confused here. Where does executing code from a public server
come
> in here? I was talking about the commands being predefined on the client
> machine. At most, the server would send  a signal telling the client
that
> something in the repository has changed. So unless you are automatically
> executing code that is in the repository (ya, that would be stupid) I
faill
> to see where executing arbitrary commands  automatically comes in here.

Your shell configuration files are actually programs.

The "rc" on many of those configuration files stands for "run command".
(Or "run commands", I suppose.) An un-human-mediated update of an rc file
is effectively the same as giving someone the ability to run arbitrary
code on the target system.

Every time you spawn a new shell -- such as when you bring up a new
xterm -- .cshrc (if a csh user) or .bashrc (of a bash user) etc. etc.
files are "run".

Most of the common user-shells in *NIX also have scripts that run on
login and logout. A demon that updates all your remote accounts
automatically
would basically *give* access to all of your remote accounts to anyone
who cracks _one_ of your accounts.

The same goes for ssh and authorized_keys, really... in fact, that
would probably be the best form of attack -- dump a known key into
the ~/.ssh/authorized_keys file (put it under configuration control
if need be!).  Even dead data can be dangerous.

Hmph. This would be fun to experiment with.


Well as someone mentioned earlier, you wouldn't do this to your ~/ directory
but something like ~/rev. doing your  home directory  might have other
consequences  such as apearance and  browser caching, as others have already
mentioned. I suppose I should have clarified this, that is, I meant putting
a directory under your home directory under revision control.

If you did want to do revision control of your home directory, simply ommit
~/.* . For me this is impractical because I have massive binary files such
as movies and anime. It wouldn't take long for me to fill up my svn (many
anime series take up ~7Gb)

--
_ |\_
\|


--
[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

Reply via email to