On Mon, Dec 27, 2010 at 01:28:34PM -0800, Philip Prindeville wrote:
> On 12/27/10 11:34 AM, Ryan Schmidt wrote:
> >On Dec 24, 2010, at 23:34, Philip Prindeville wrote:
> >
> >>Unfortunately, the documentation and utilities in a few places are less clear than they could be when discussing repository setup for svnserve versus svnserve+ssh versus apache.
> >>
> >>For instance, "svnadmin create" deposits various files there:
> >>
> >>conf/svnserve.conf
> >>conf/passwd
> >>
> >>which are useful for svnserve... but not for Apache access.
> >So if you're not using svnserve, just ignore those files.
>
> We'd rather not have files laying around not serving a purpose...
> especially if in some future version they start being meaningful again
> and their contents implicitly grant some sort of access.
The configuration files won't suddently change their purpose in a
future version of Subversion (maybe in 2.0, but not before).
> When securing a machine, you start by closing everything up, and then
> opening up just what you need to accomplish the mission. "Closing
> everything up" in this context would include removing unused
> configuration files.
I don't understand why unused configuration files would be a security risk.
The important bit about security is that admins understand how to configure
the application they're setting up. They can then configure it securely.
I suppose your real concern is that you or others would get distracted
by those files. Which implies a lack of understanding about how the
system is or has been configured. I'd say the real problem here is
documenting your setup properly and making sure everyone involved knows
what this documentation says.
> In short, ignoring the files isn't an option.
Many UNIX-like operating systems come with configuration files in /etc
for applications that aren't being run unless the user enables them.
People ignore those files all the time.
In any case, you're free to simply remove configuration files that
"svnadmin create" creates. But I don't see a point in adding an
option for this because it doesn't seem to be a very common need.
Stefan
Received on 2010-12-28 12:45:12 CET