Re: Re: Configuration files...

On 1/9/07, Brian Erickson <erickson@bauercontrols.com> wrote:
>
>
> > -----Original Message-----
> > From: Andy Levy [mailto:andy.levy@gmail.com]
> > Sent: Monday, January 08, 2007 8:59 PM
> > To: Brian Erickson
> > Cc: Ryan Schmidt; users@subversion.tigris.org
> > Subject: Re: Re: Configuration files...
> >
> > On 1/8/07, Brian Erickson <erickson@bauercontrols.com> wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Ryan Schmidt [mailto:subversion-2007a@ryandesign.com]
> > > > Sent: Monday, January 08, 2007 5:37 PM
> > > > To: Brian Erickson
> > > > Cc: Andy Levy; users@subversion.tigris.org
> > > > Subject: Re: Configuration files...
> > > >
> > > > On Jan 8, 2007, at 16:19, Brian Erickson wrote:
> > > >
> > > > > Andy Levy wrote:
> > > > >
> > > > >> On 1/8/07, Brian Erickson wrote:
> > > > >>
> > > > >>> I'm trying to understand how Subversion deals with
> > system-wide
> > > > >>> configuration properties and can't figure it out.
> > I've read the
> > > > >>> docs but am still clueless. I'm hoping someone can help me.
> > > > >>>
> > > > >>> I'm using windows XP and all my users will access the
> > repository
> > > > >>> using the FILE:// syntax.
> > > > >>>
> > > > >>> 1) Is there a way to set options that every user
> > accessing the
> > > > >>> repository will have?
> > > > >>> Specifically, I'm looking to ignore things like
> > > > object files and
> > > > >>> such as well as an editor for when the -m option is missing.
> > > > >>
> > > > >> Client configuration is per-user. There is currently no
> > > > way to set a
> > > > >> particular configuration from the "server" (I put this in
> > > > quotes as
> > > > >> you have no real server when using file://).
> > > > >>
> > > > >>> 2) If it's possible, where do these file(s) go? what is
> > > > the format?
> > > > >>
> > > > >> Each user's config is in %APPDATA%\subversion\config . It's a
> > > > >> plain-text file. Documentation is included within.
> > > > >>
> > > > >>> 3) Right now, I've locked down branches in the tags
> > > > folder using the
> > > > >>> pre-commit hook. Can I do the same thing in the "authz" file
> > > > >>> (remember I'm using the FILE:// syntax)?
> > > > >>
> > > > >> Using file://, it's all or nothing - users either have
> > > > access to the
> > > > >> repository (via the host OS's permissions - NTFS & share
> > > > permissions
> > > > >> in your case, I'm guessing), or they don't. This means
> > > > they can very
> > > > >> easily hose the whole setup.
> > > > >>
> > > > >> file:// really isn't suited to a multi-user environment -
> > > > it's best
> > > > >> for single-user setups, and testing/debugging. You
> > really ought
> > > > >> to consider serving via svnserve or Apache.
> > > > >
> > > > > It's interesting that the Subversion developers chose
> > to put the
> > > > > client configuration in a hidden folder...Did I just miss
> > > > this in the
> > > > > docs?
> > > >
> > > > The book does state the name and location of the configuration
> > > > directory, and does note that this directory is usually
> > hidden. It
> > > > does not seem to say why.
> > > >
> > > > http://svnbook.red-bean.com/en/1.2/
> > > > svn.advanced.html#svn.advanced.confarea
> > > >
> > > > On Unix, it is usual for programs to put their
> > configuration files
> > > > into directories in the home directory whose names begin with a
> > > > period, which by default makes them hidden. I don't know what's
> > > > usual on Windows.
> > > >
> > > >
> > > > > You're right there is no server but everyone is accessing a
> > > > repository
> > > > > on a server. That's why the hooks work. For each repository
> > > > > there appears to be a hooks folder. I was hoping that
> > I could put
> > > > > some files somewhere else on the server to define a
> > common configuration.
> > > >
> > > > But unfortunately, you can't; Subversion doesn't have server-side
> > > > client configuration.
> > > >
> > > >
> > > > > My situation appears to be quite different from most users
> > > > sending to
> > > > > this list. I will never have a customer accessing the
> > > > repository.
> > > > > The
> > > > > only people accessing the repository will be programmers
> > > > working for
> > > > > Bauer Controls. The repository is stored on an in-house server
> > > > > and (at least today) we have no need to access it from
> > outside the
> > > > > company.
> > > > >
> > > > > Further more none of our programmers have full time
> > > > responsibilities
> > > > > in a particular sub-set of our projects. The net effect is
> > > > that our
> > > > > programmers needs to have access the entire repository
> > all of the
> > > > > time.
> > > >
> > > > That setup doesn't sound so uncommon. We also had our
> > repository on
> > > > a central development server in the same building as all the
> > > > developers. We ended up serving with
> > > > apache2 because as web developers we're familiar with it,
> > and it let
> > > > us access the repository from outside the company securely using
> > > > https, which was a bonus for those times when someone needed to
> > > > check something out from home.
> > > >
> > > >
> > > > > Given all this, I'm interested in why you say the file://
> > > > isn't suited
> > > > > to multi-user scenarios. It seems to fit quite nicely for
> > > > me. I've
> > > > > used hooks to lock down the parts of the repository that are
> > > > > restricted to a particular user. Am I going to run into file
> > > > > corruption issues or something?
> > > >
> > > > Anyone who has access to a repository via file:// protocol has
> > > > *complete* access to it. You can install hooks, but
> > anyone can edit
> > > > or remove them, or copy the entire repository to their
> > local disk to
> > > > use as they please. Anyone can even delete the entire repository
> > > > using their OS-level file browser with your only recourse
> > being to
> > > > restore from backups, if you have them.
> > > >
> > >
> > > It's actually quite easy to restrict access to the hooks
> > folder so the
> > > scripts can't be removed or modified.
> >
> > But that doesn't protect the repository contents.
>
> In my case is does. The only protection I want/need is for the three
> special folders. Two underneath branches and everything underneath the
> release (tags) folder. The hooks protect those.
>
> I had thought, from reading posts here, that it was common practice to
> use hooks to protect different part of the repository.

The more-common (and accepted, in multiple-user setups) is to use
hooks to *augment* the built-in access controls built into svnserve
and mod_dav_svn. If you were to use an actual SVN server, you might be
able to avoid the hooks for security altogether.

> >
> > > As for the rest, it's all true but our programmers have had
> > this kind
> > > of access to the source for the last 20 years and we've not
> > had any of
> > > the issues you raise. So, I'm not concerned... We do have
> > a backup scheme.
> > > We can go back for a year and that's served us very nicely.
> >
> > Just because you haven't had a problem before doesn't mean
> > you won't in the future (past performance does not predict
> > future results). Take this opportunity now to improve your
> > processes and security. If you're going to use version
> > control software, use the capabilities it offers to improve
> > how you do things - don't just treat it as a glorified
> > filesystem/server.
> >
> I agree that past performance doesn't predict future results. However,
> right now I don't see svnserve or Apache as ways to improve anything.
> They just add complications - granted small ones. I can tell that you
> think I'm missing something fundamently important but I just don't see
> it...

> Let me make this perfectly clear. I don't want or need this kind of
> protection. I trust our empolyees. Always have and always will. Yes
> we will probably get burned eventually. If this is the best argument
> for using an SVN server, I don't need one. Anything else? :)

Do you ever get audited? Got any ISO standards you need to meet,
industry requirements, CMM, anything like that?

Might you ever need to offer access to the repository to people who
don't have access to the fileserver?

Might you want to make portions of the repository available to people
via a simple, read-only interface instead of having to use a
Subversion client and full working copy?

By using file:// access, *ANYONE* can delete the whole repository with
a single errant keystroke. This isn't even about "trust", it's about
mistakes. Stuff happens. Using svnserve or Apache, it's possible to
delete the contents, but because it's a versioned operation, it's just
as simple to undo the delete as it is to do the delete.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 9 14:58:04 2007