Comment 8 for bug 10560

On Tuesday 23 November 2004 21.38, Philip Martin wrote:
> Adrian 'Dagurashibanipal' von Bidder <email address hidden> writes:
> > On Monday 22 November 2004 12.28, Wilfried Goesgens wrote:
> >> Package: subversion
> >> Version: 1.0.9-2
> >> Severity: serious
> >>
> >> as the subversion book states, one should create a wrapper script
> >> arround the subversion binaries to keep them from screwing the berkley
> >> db and their file permission.
> >
> > I think this is a bug in subversion - the svn binary should take care
> > about this, and not require a wrapper script.
>
> The problem with forcing umask to 002 (whether by wrappers or in the
> binaries) is that it could be considered a security bug as it means a
> user may inadvertently allow group write access to repositories that
> should be private.

That's why my pseudocode reads:

> > if (db is g+w) { umask 002 }

So, no private repositories will become group writable just so.

> The non-BDB backend in Subversion 1.1 propogates repository
> permissions to new files as such files are created by Subversion
> directly.

For me, as subversion users, files in the db are 'created by subversion
directly', too. As a user, I regard svn as a black box, and when I set the
subversion repository g+w, svn has no business messing around with this.

Same goes for the group ownership - new files should be created with the
same group as the other files in the repository.

There's no security issue that I can see here: all that happens is that new
files get the same ownership and permissions as the existing files, no
access permission is given that does not already exist.

Imagine an editor which would save files with permissions & ~umask after
every edit, and change group ownership to whatever is the default group of
the current user.

greetings
-- vbi

--
TODO: apt-get install signify