WebDAV Support

[jsteel]

Is there any particular reason why the default builds within CPanel don't have WebDAV supported? I've had many people ask for this recently and it seems like a no brainer given that it is more secure that FrontPage, yet FrontPage is supported.

Thngs that make you go hmmmm...

[itf]

Because FrontPage is more popular ...

[jsteel]

That's not exactly a good reason. There's no harm in supporting both (besides, DAV is an IETF standard and is actually supported by Microsoft in their WebFolders implementation).

Since DAV is just an extension to HTTP/1.1, it doesn't interfere with things like FrontPage. There's no proprietary API that has to be installed (like FrontPage). Seems like a no-brainer to include mod_dav as part of the standard Apache build.

They're (DAV vs. FP) are two entirely different creatures. Stating that a reason like 'FrontPage is more popular' is a pretty moot point.

[feanor]

Ok-

Your solution is as follows:

In advanced mode of cpanel's buildapache on layer1, add the module. Or, compile it from source yourself and add it by hand. For an ultimate solution, submit an &enhancement request& via Bugzilla and if demand is high enough support will be built in by default.

[itf]

As -- feanor -- wrote you can add it yourself just run /scripts/easyapache select advanced and choose DAV module while you select other required modules

But FrontPage is proprietorship software all of its users have paid for it, if you don't support FrontPage those users would go and choose a Host who supports it.

This is why FrontPage is supported by default in Cpanel.

[b:28e5c95b4a]mod_DAV Possible security attacks[/b:28e5c95b4a]
Mostly, the DAV server is subject to Denial of Service attacks. These are listed below:

If a user submits a PROPFIND, PROPPATCH, or LOCK request with a huge XML body, then the DAV server will parse that into memory. The process memory usage could grow and consume all available memory and swap space on your server.
By default, mod_dav is compiled with a one million byte (1000000) limit on the size of the XML request body. This limit may be changed by using the LimitXMLRequestBody configuration directive.

A PROPFIND request with a Depth: Infinity header can cause mod_dav to walk the entire repository, building up a response (in memory) for the properties on each resource found. With a large repository, this can consume a lot of memory (the memory will be released when the request has been completed, but the peak can be troublesome).
By default, mod_dav does not allow these kinds of requests. This behavior may be changed by using the DAVDepthInfinity directive.

[Mysticeti]

[quote:f0495ceb8e]By default, mod_dav does not allow these kinds of requests. This behavior may be changed by using the DAVDepthInfinity directive. [/quote:f0495ceb8e]

In my opinion the DoS risk of a poperly configured Apache/mod_dav is very, very low (never say never).

Nobody is going to configure mod_dav w/o authentication directives so in order to for someone to issue a DoS attack they'd first need to break into a user's account. Should that occur it's simple to disable that account to stop the DoS attack.

[itf]

[quote:658603ef4d][i:658603ef4d]Originally posted by itf[/i:658603ef4d]

As -- feanor -- wrote you can add it yourself just run /scripts/easyapache select advanced and choose DAV module while you select other required modules

But FrontPage is proprietorship software all of its users have paid for it, if you don't support FrontPage those users would go and choose a Host who supports it.

This is why FrontPage is supported by default in Cpanel.

[b:658603ef4d]mod_DAV Possible security attacks[/b:658603ef4d]
Mostly, the DAV server is subject to Denial of Service attacks. These are listed below:

If a user submits a PROPFIND, PROPPATCH, or LOCK request with a huge XML body, then the DAV server will parse that into memory. The process memory usage could grow and consume all available memory and swap space on your server.
By default, mod_dav is compiled with a one million byte (1000000) limit on the size of the XML request body. This limit may be changed by using the LimitXMLRequestBody configuration directive.

A PROPFIND request with a Depth: Infinity header can cause mod_dav to walk the entire repository, building up a response (in memory) for the properties on each resource found. With a large repository, this can consume a lot of memory (the memory will be released when the request has been completed, but the peak can be troublesome).
By default, mod_dav does not allow these kinds of requests. This behavior may be changed by using the DAVDepthInfinity directive.
[/quote:658603ef4d]
[quote:658603ef4d][i:658603ef4d]Originally posted by Mysticeti[/i:658603ef4d]

[quote:658603ef4d]By default, mod_dav does not allow these kinds of requests. This behavior may be changed by using the DAVDepthInfinity directive. [/quote:658603ef4d]

In my opinion the DoS risk of a poperly configured Apache/mod_dav is very, very low (never say never).

Nobody is going to configure mod_dav w/o authentication directives so in order to for someone to issue a DoS attack they'd first need to break into a user's account. Should that occur it's simple to disable that account to stop the DoS attack.
[/quote:658603ef4d]

Mysticeti,

I cannot see any reason why did you offer such an idea, as I wrote how to protect yourself against DoS attacks in my post, I [b:658603ef4d]never wrote[/b:658603ef4d] that you have not to compile in mod_dav with your Apache, but you have to know what to do with your settings in httpd.conf to prevent DoS attacks.

Also you wrote:
[b:658603ef4d] Mysticeti [/b:658603ef4d]& “In my opinion the DoS risk of a properly configured Apache/mod_dav is very, very low (never say never).”

ITF & In general it is not a professional or scientific or even technological idea when you don’t know about risks and safety of other elements on a system, security could not be achieved by opinions it requires actual reaction against possible attacks as you can read in [b:658603ef4d]“mod_DAV Possible security attacks”[/b:658603ef4d] section of my post

i.e you quoted this paragraph from my post : “By default, mod_dav does not allow these kinds of requests. This behavior may be changed by using the DAVDepthInfinity directive.”

It means by adding this directive to appropriate section of httpd.conf
DAVDepthInfinity on
You can solve this kind of DoS attacks,

In this section of my post: [b:658603ef4d]“mod_DAV Possible security attacks”[/b:658603ef4d] I wrote hints about what settings should be done against possible DoS attacks

Also you wrote at your second paragraph:
[b:658603ef4d] Mysticeti [/b:658603ef4d]& “Nobody is going to configure mod_dav w/o authentication directives so in order to for someone to issue a DoS attack they'd first need to break into a user's account. Should that occur it's simple to disable that account to stop the DoS attack.”

You haven’t considered three things.
First: users who have access to the system can also make a DoS attack,
Second: it is possible to obtain a user’s login and password with a Trojan horse or some other techniques from their workstations, and
Third: you accepted that after DoS attack you will remove that user but what you don’t consider is; after a successful DoS attack your server could not be accessed remotely as DoS attack is Denial of Service attack and we do all of these protections for system uptime and reducing unavailability of the servers (server down) which in business means losing money.