Message-Id: <email address hidden>
Date: Wed, 24 Nov 2004 08:40:13 +0100
From: Adrian 'Dagurashibanipal' von Bidder <email address hidden>
To: Philip Martin <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#282468: subversion binaries should be replaced through wrapper scripts to prevent
users of keep on screwing their repositories
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.
=46or me, as subversion users, files in the db are 'created by subversion=20
directly', too. As a user, I regard svn as a black box, and when I set the=
=20
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=20
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=
=20
files get the same ownership and permissions as the existing files, no=20
access permission is given that does not already exist.
Imagine an editor which would save files with permissions & ~umask after=20
every edit, and change group ownership to whatever is the default group of=
=20
the current user.
Message-Id: <email address hidden>
Date: Wed, 24 Nov 2004 08:40:13 +0100
From: Adrian 'Dagurashibanipal' von Bidder <email address hidden>
To: Philip Martin <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#282468: subversion binaries should be replaced through wrapper scripts to prevent
users of keep on screwing their repositories
--nextPart13897 94.hRnnf5KygB "iso-8859- 1" Transfer- Encoding: quoted-printable Disposition: inline
Content-Type: text/plain;
charset=
Content-
Content-
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.
=46or me, as subversion users, files in the db are 'created by subversion=20
directly', too. As a user, I regard svn as a black box, and when I set the=
=20
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=20
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=
=20
files get the same ownership and permissions as the existing files, no=20
access permission is given that does not already exist.
Imagine an editor which would save files with permissions & ~umask after=20
every edit, and change group ownership to whatever is the default group of=
=20
the current user.
greetings
=2D- vbi
=2D-=20
TODO: apt-get install signify
--nextPart13897 94.hRnnf5KygB pgp-signature
Content-Type: application/
-----BEGIN PGP SIGNATURE----- fortytwo. ch/gpg/ 92082481
kOuJgGmh0dHA6Ly 9mb3J0eXR3by5ja C9sZWdhbC9ncGcv ZW1h /dmVyc2lvbj0xLj UmbWQ1c3VtPTVkZ mY4NjhkMTE4NDMy NzYw kYTNlAAoJECqqZt i935l6WbYAoKH8O RRlE/+HtwPhCBrl NFMz xseUXR6Fa/ DtBi27MXA= =
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: get my key from http://
iKcEABECAGcFAkG
aWwuMjAwMjA4MjI
NzFiMjVlYjcwMDZ
d6QhAJ4hu9H2ZXb
=ttG4
-----END PGP SIGNATURE-----
--nextPart13897 94.hRnnf5KygB- -