On Tue, 2004-03-16 at 17:59, Ben Reser wrote:
> > I think we have to keep the old implementation under the old name, and
> > introduce a new function name with the new behaviour. By all means
> > write more explicit documentation disparaging the old interface ;-)
>
> This was originally my opinion. But everyone told me I was wrong off
> list. If people feel differently due to the issue not being a security
> issue now then I'll be happy to make a different function.
To clarify my opinion on this matter:
Right now, svn_io_set_file_read_write() effectively does a chmod a+w.
I think it would be reasonable to make it do a chmod u+w and treat that
as a bugfix rather than an API change. It may be a good idea to do this
in svn 1.0.x, for the marginal security value. (Most of the files we
set to read-write are then immediately deleted, so it doesn't matter if
anyone writes to them first; we believe the only exception is the format
file, and there isn't a lot of utility in seizing the short window of
writability to write data into the format file.)
I don't think it would be reasonable to make it into a no-op.
If we want to enable shared working directories (in 1.1), perhaps the
best option is to introduce a function private to libsvn_wc, which
invokes svn_io_set_file_read_write only on Windows. (Our ABI rules
allow us to do this in svn 1.0.x, but it's a new feature, not a bugfix,
so we shouldn't do so.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 17 00:07:33 2004