You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2003/11/30 16:14:04 UTC
RFC: svnserve.conf umask directive
We could add a "umask" directive to the repository's
conf/svnserve.conf, so that people could set svnserve's umask that way
instead of wrapping svnserve in a script which sets the umask.
There is no APR interface to umask(); we'd either have to add one
(along with APR_HAS_UMASK, since the concept is very Unix-specific),
or just write some #ifdef'd Unix-specific code.
The directive would be most useful for tunnel mode, but in some
configurations people might find it a useful sanity check for daemon
mode. Unfortunately, there lies a catch: if on Unix you run svnserve
-d -T (threaded mode), and you have multiple repositories with
different umask directives, you will not get predictable behavior,
because the umask is process-global state.
So, we have two orthogonal sets of options. On the portability axis:
* Decide not to implement this, because it's Unix-specific.
* Add APR interface to umask. (If you recommend this option, let me
know where you think it fits into APR, if possible.)
* Wrap umask code in HAVE_UMASK, and add an AC_CHECK_FUNCS(umask) to
configure.in (we don't have any other AC_CHECK_FUNCS directives
currently). Or, ifdef it some other way. If we go with #2, we
could also do this as a stopgap while we wait for the apr code to
percolate into an Apache release.
On the failure to work properly in threaded mode:
* Decide not to implement this, because of the threaded mode issue.
* Make the umask option apply only to tunnel mode, avoiding the
issue.
* Remove the -T option, so that threaded mode only applies to
systems without APR_HAS_FORK. (Every system which has umask()
also has fork(), I am certain.) I didn't like the -T option in
the first place, so I like this choice, but I'm sure Phillip would
object.
* Undocument the -T option, and call it a debugging aide in the help
output.
* In the svnserve.conf comments, document that "umask" won't work
right with the -T option unless you make the umask consistent
across all repositories served by svnserve.
* Check for the "umask" directive being used in combination with the
-T option, and error out. I don't like this option because it
would be complicated to implement, and because it would preclude
setting the umask consistently across repositories.
* Silently ignore the "umask" directive when used in combination
with the -T option. Again, I don't like the idea of implementing
this, and it doesn't sit right with me.
Comments?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: svnserve.conf umask directive
Posted by Kalle Olavi Niemitalo <ko...@iki.fi>.
Ben Reser <be...@reser.org> writes:
> Nope, getumask isn't available at all.
Except on GNU/Hurd, where glibc-2.3.2/sysdeps/mach/hurd/umask.c
and glibc-2.3.2/hurd/getumask.c simply write and read the
_hurd_umask variable. (The man page seems to be wrong about
locks; I don't see any in the code.)
I presume most Subversion servers are not running on the Hurd.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: svnserve.conf umask directive
Posted by John Peacock <jp...@rowman.com>.
Ben Reser wrote:
> Nope, getumask isn't available at all. If you go back and re-read that
> man page you'll note it isn't implemented and is vapourware. :(
>
Oops; you're right! I didn't read that section carefully enough...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: svnserve.conf umask directive
Posted by Ben Reser <be...@reser.org>.
On Sun, Nov 30, 2003 at 08:35:30PM -0500, John Peacock wrote:
> It appears that on some architectures, getumask() is available (and is
> supposed to be threadsafe), but all others would have to use:
Nope, getumask isn't available at all. If you go back and re-read that
man page you'll note it isn't implemented and is vapourware. :(
I think the man page is a bit of a joke and exists so people can figure
out how to find out what the current umask is while warning them about
the thread issues.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: svnserve.conf umask directive
Posted by John Peacock <jp...@rowman.com>.
Tobias Ringstrom wrote:
> A solution could perhaps be to only check that the current umask is
> correct, and abort if not. That would prevent repository "corruption"
> and let the user fix the problem. Unfortunately I'm not sure if it's
> possible to read the umask without setting it. Anyone?
>
It appears that on some architectures, getumask() is available (and is supposed
to be threadsafe), but all others would have to use:
mode_t getumask(void) {
mode_t mask = umask(0);
umask(mask);
return mask;
}
[direct quote from the getumask man page) and worry about threads conflicting.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: svnserve.conf umask directive
Posted by Tobias Ringstrom <to...@ringstrom.mine.nu>.
Greg Hudson wrote:
> * Decide not to implement this, because it's Unix-specific.
+1
Not mainly because it's Unix-specific, but because I don't think it
really solves the problem. Most of the problems seem to occur when
you mix different access methods, so any real fix need to be
independant of the access method.
If it is to be implemented for all access methods, I think that the
fact that the umask is process global is a problem for ra_dav as well,
since it too can be threaded. Please correct me if I'm wrong.
A solution could perhaps be to only check that the current umask is
correct, and abort if not. That would prevent repository "corruption"
and let the user fix the problem. Unfortunately I'm not sure if it's
possible to read the umask without setting it. Anyone?
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: svnserve.conf umask directive
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> * Add APR interface to umask. (If you recommend this option, let me
> know where you think it fits into APR, if possible.)
apr_file_io would be the most obvious place, I would think, though apr_file_info
would be a close second.
> * Wrap umask code in HAVE_UMASK, and add an AC_CHECK_FUNCS(umask) to
> configure.in (we don't have any other AC_CHECK_FUNCS directives
> currently). Or, ifdef it some other way. If we go with #2, we
> could also do this as a stopgap while we wait for the apr code to
> percolate into an Apache release.
If you do this you also have to make sure the applicable code has
#include "svn_private_config.h"
in order to gather the AC_CHECK #defines.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org