On 01 Feb 2012, at 5:53 PM, Brian J. France br...@brianfrance.com wrote:
I had started breaking up the patches from mod_dav_acl into smaller chunks
and getting them imported into the trunk.
My goal was to get a mod_dav_acl like module added. I say like because
mod_dav_acl currently
I had started breaking up the patches from mod_dav_acl into smaller chunks and
getting them imported into the trunk.
My goal was to get a mod_dav_acl like module added. I say like because
mod_dav_acl currently requires xfs and stores the auth information in the xfs
attributes and I wanted to
On 01 Feb 2012, at 5:38 PM, Andreas wrote:
Where can I find out if httpd/mod_dav has support for ACL's?
After digging in the mailinglist, there seem to have been some activity
about the topic in 2007 and 2009 but no patches seem to be applied.
I checked today on 2.3beta, there is no
Yeah: mod_dav itself has no direct support for ACLs.
Way back when, when I wrote mod_dav and was working on DAV stuff in
general, the ACL stuff created an interesting problem: how to
propagate access control changes to all the httpd processes. If the
processes do not contain the ACLs, then the
This version of path support COPY resources to remote servers with
respect to Overwrite header.
TODO: support MOVE
TODO: support collections
Tysiące pomysłów na urządzanie domu, mieszkania,
ogrodu w jednym miejscu!
Zobacz jak mógłbyś
If people *really* think that this functionality is needed,
My boss think ;) And I agree with him ;)
than
re-using COPY seems to make more sense (we could define a new variant
that takes a Source header instead of the currently mandatory
Destination header).
I've attached a path thats allows
Rafa%u0142 wrote:
Hello!
I've done first part of the job - there is now a FETCH method that works
in that way:
FETCH /destination/path HTTP/1.1
Source: http://webdav.example.com/webdav-resource-to-fetch
...
I'm not sure it's a good idea to define a new method for that.
If people *really*
Dnia 17-07-2008 o godz. 9:14 Julian Reschke napisał(a):
Rafał wrote:
Hello!
I've done first part of the job - there is now a FETCH method that works
in that way:
FETCH /destination/path HTTP/1.1
Source: http://webdav.example.com/webdav-resource-to-fetch
...
I'm not sure it's
But now I know apache and mod_dav better that a week ago, so I'll check
if it is possible to reuse COPY method with Destination header.
It is possible, but I cannot find a function that tells me if a char *
value represents current hostname/ip address so I could tell when to use
remote or
Hello!
I've done first part of the job - there is now a FETCH method that works
in that way:
FETCH /destination/path HTTP/1.1
Source: http://webdav.example.com/webdav-resource-to-fetch
It fetches resource http://webdav.example.com/webdav-resource-to-fetch
(with GET method) and stores it in
Rafa%u0142 wrote:
Hello.
My name is Rafał Malinowski. I want (really, I have to) add one feature
to WebDav: support for MOVE/COPY with remote servers as 'Destination'.
Why? Do you have any clients that would use it?
As I looked into code and into specification such thing is allowed, but
Dnia 3-07-2008 o godz. 13:22 Julian Reschke napisał(a):
Rafał wrote:
Hello.
My name is Rafał Malinowski. I want (really, I have to) add one feature
to WebDav: support for MOVE/COPY with remote servers as 'Destination'.
Why? Do you have any clients that would use it?
I will use telnet.
Rafa%u0142 wrote:
Dnia 3-07-2008 o godz. 13:22 Julian Reschke napisał(a):
Rafał wrote:
Hello.
My name is Rafał Malinowski. I want (really, I have to) add one feature
to WebDav: support for MOVE/COPY with remote servers as 'Destination'.
Why? Do you have any clients that would use it?
I
- Original Message -
From: Rafa%u0142 [EMAIL PROTECTED]
To: dev@httpd.apache.org
Sent: Wednesday, July 02, 2008 1:22 AM
Subject: WebDav MOVE/COPY between servers
Hello.
My name is Rafał Malinowski. I want (really, I have to) add one feature
to WebDav: support for MOVE/COPY with
I imagine most will allow copying to and from local file systems... so you
on your way.
My purpose is to get rid of it in some cases. For example: I have my
client system, and 2 webdav servers (dav1, dav2). I want to be able to
copy/move files between dav1 and dav2 without copying them first
Hi,
Something like FXP (for ftp server) for WebDav would indeed be nice.
Although if you are looking to syncronize servers (not sure you are though)
rsync may be a better way.
Jorge
On 7/2/08, Rafa%u0142 [EMAIL PROTECTED] wrote:
I imagine most will allow copying to and from local file
- Original Message -
From: Rafa%u0142 [EMAIL PROTECTED]
To: dev dev@httpd.apache.org
Sent: Wednesday, July 02, 2008 1:33 PM
Subject: Re: WebDav MOVE/COPY between servers
I imagine most will allow copying to and from local file systems... so
you
on your way.
My purpose is to get
* Graham Leggett [EMAIL PROTECTED] wrote:
Hi,
I am busy researching the idea of an Apache + DAV server that would do
the job of what a typical Samba server does now - file sharing. An
Apache server would have the advantage of native SSL support, flexible
authentication configuration, etc.
* Sander Temme [EMAIL PROTECTED] wrote:
snip
Could you mount the DAV filesystem on the local box, so that all access
would go through DAV? That way all access would go through Apache and
it could have its own sandbox.
a) are there *working* DAV filesystem drivers for several OS'es
b)
* Graham Leggett [EMAIL PROTECTED] wrote:
snip
But if this proper filesharing concept is to work properly, then at some
point the DAV server will have to support some kind of interaction with
the filesystem along far better lines than the current one user owns all.
Another point: why not
* Joshua Slive [EMAIL PROTECTED] wrote:
Hi,
Yes. I don't know of anyone successfully using perchild. There is another
group working on a successor called something like mpmmux, but they've
been rather quite too.
metuxmpm has been reported to be running successfully in production
On Fri, Apr 30, 2004 at 08:09:13PM +0200, Graham Leggett wrote:
André Malo wrote:
Hmm. I suspect, the difference is, that Apache was never designed to run as
root.
You're assuming the root account is the most damaging account to
compromise. In the case of a fileserver, you will very
On Fri, Apr 30, 2004 at 11:29:45AM +0530, Amit Athavale wrote:
Greg Stein wrote:
...
My POV has been (for a LONG while now): the DAV repository is private to
the web server and the mod_dav module. Don't let local users near it.
May be DAV ACL is the way to go ?
Nope. That is only about
Sander Temme wrote:
On Apr 29, 2004, at 10:59 PM, Amit Athavale wrote:
May be DAV ACL is the way to go ?
AFAIK WebDAV+ACL+some kind authentication serves the purpose where each
user having it own area and he can play with permissions of files
and yet you have
private repository and user
Greg Stein wrote:
Eesh. This has tended to come up w.r.t mod_dav for over five years now. My
point of view is best summarized in this email:
http://mailman.lyra.org/pipermail/dav-dev/2000-November/001746.html
I really don't recommend it. Why do you need to have different owners for
the files?
Joshua Slive wrote:
If you really want apache to behave like samba, then I suppose you don't
mind if apache runs as root. Then it becomes rather more simple to do the
sort of things you are interested in. It also becomes rather more simple
to compromise your box.
If I don't run Apache, then I
* Graham Leggett [EMAIL PROTECTED] wrote:
Keep in mind the application I am thinking about is not webserver
that's trying to be a fileserver, but rather a fileserver that just
happens to use the DAV protocol. I don't see the security risks of
running Apache as root as being any different
André Malo wrote:
Hmm. I suspect, the difference is, that Apache was never designed to run as
root.
You're assuming the root account is the most damaging account to
compromise. In the case of a fileserver, you will very likely want some
files kept more private than others. If I as a hacker
On Apr 30, 2004, at 10:26 AM, Graham Leggett wrote:
Keep in mind the application I am thinking about is not webserver
that's trying to be a fileserver, but rather a fileserver that just
happens to use the DAV protocol. I don't see the security risks of
running Apache as root as being any
On Thu, Apr 29, 2004 at 02:50:19AM +0200, Graham Leggett wrote:
Hi all,
I am busy researching the idea of an Apache + DAV server that would do
the job of what a typical Samba server does now - file sharing. An
Apache server would have the advantage of native SSL support, flexible
Greg Stein wrote:
One thing I would like to be able to do is have the DAV server read and
write files as system users, along the lines of what suexec achieves for
cgi programs. Obviously the DAV server would need to run as root (or
have some mechanism like suexec) in order to
On Thu, 29 Apr 2004, Graham Leggett wrote:
The perchild mpm seems to be the closest thing to what I am looking for,
but the manual warns that it is not functional. Is this still the case?
Yes. I don't know of anyone successfully using perchild. There is another
group working on a successor
We operate a WebDav site, currently on
Apache 2.0.42, but operating in the same
manner since 2.0.16...
...Our users are able to create, move,
copy, and delete files.
We have Apache running as user nobody
and group nobody (but started as root)...
...we are using the worker model.
The all of
You don't have to run Apache 2.0 as root
in order to provide webdav capability...
...If you are running as user 'nobody',
just ensure that the directory tree that
is dav enabled is owned by user 'nobody'.
-tony
-Original Message-
From: Martin Ouimet [mailto:[EMAIL PROTECTED]]
Sent:
this is impossible because im sharing all my user's home directory via webdav.
-Original Message-
From: Bennett, Tony - CNF [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 12, 2002 11:48 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Webdav
You don't have to run Apache 2.0 as root
: RE: Webdav
this is impossible because im sharing all my user's home
directory via webdav.
-Original Message-
From: Bennett, Tony - CNF [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 12, 2002 11:48 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Webdav
You don't have to run
36 matches
Mail list logo
