Bruce,

Security in WebDAV is a good topic.  It could actually be discussed on the forum, and I'm moving your security question (at the end of this post) back "on-list."  I trust you won't object.

WebDAV security is derived from the underlying system, and what is permitted would depend on the capabilities of that system.  WebDAV is just the protocol to communicate the message.  ("Don't kill the messenger!" :) ) 

Bruce, WebDAV, itself, cannot fix flaws in the underlying operating system, but it should allow us to effectively use the operating system features that are present.  Over time, useful features tend to be adopted by more systems, and flaws tend to be either rectified, or these systems fall into disuse.

I think a bit of background on my suggestion that we have an additional WebDAV HTTP header for delete processing would clarify its goals:

I've been working on enterprise WebDAV implementations for the last year, primarily using the Xythos server.  Xythos provides a very handy option to allow deleted files to be automatically stored in a trash folder associated with the particular root directory.  This is great for the "oops" factor where one wants to recover a deleted file, and complements their automatic versioning facility.

Other implementations, of course, have different schemes, and this is why it would be good to be able to express the original DELETE request more fully in WebDAV.

We have four use cases where we do not want this trash-foldering to happen:

1.  The user wrote something (perhaps in haste, or perhaps something that was confidential) that he/she does not want to be subsequently read by others either within the organization, or through the legal discovery process.

2.  The document was being added by a program within a long-running unit-of-work and we want to do a rollback, rather than a commit, after it has already been stored and committed to the document server.  Here we want to avoid wasting space.

3.  Documents are being moved to long-term archive storage and deleted from the operational system to free space.  This is done by a records retention application on a recurring (perhaps yearly) basis.  By definition, we want to delete it completely from the operational system.

4.  The user was using the file system to hold documents (and versions) temporarily as work-in-process.  When the document is deemed finished ("Published") the temporary work products should not be retained.

We like having the trash folder, so our current "work-around" to permanently delete a document is to issue two deletes.  First for the document, and then for the trash folder copy.  This requires the client (human or application) to know about the trash folder and have permission to delete stuff from it.

It would be better if a single DELETE could communicate the entire request.  This avoids having the client know the structure of the repository, have access to the trash folder, and avoids unit-of-work problems when multiple requests are required to fulfill the delete process.

As for security permissions, the Access Control List mechanism is quite appropriate to determine if the user should be allowed to issue a permanent delete request.  This would require a degree of granularity in the ACL permission structure to differentiate between a simple delete and a more complex one.  The WebDAV ACL group has been doing great work in this area.

Additionally, we use the HTTP User-Agent" header to further "lock-down" permissions.  We grant out-of-the-box clients, such as Microsoft Office, a reduced set of functions, than our programmed clients.  Thus a long-running-unit-of-work client program and an archiving client program would have unique User-Agent strings that are allowed to do things that the same userid/ACL could not do using their desktop clients. 

Of course, another of the nice things about WebDAV is that it uses HTTP, which allows the use of SSL -- if transmission interception of these headers was an issue.

By adding a new delete header, the goal would be to have WebDAV fully communicate the client's intent in a single HTTP request.  How the server honors the request depends on the implementation.  If the installation is using a programmable server then they can customize this behavior to satisfy their business requirements.

I think an environment of appropriate security can thus be built using WebDAV.  I don't view the 'trash' folder as an OS flaw, but as a capability that serves to benefit the user community.  It needs to be implemented and managed to meet business document retention requirements, and also eliminate the potentially wasteful accumulation of truly dead documents.  Bruce, I think you are quite correct, if we are to have a secure environment, it will indeed take a overt effort to this end, and this requires a thoughtful technical implementation of WebDAV clients and servers.

Gary

At 11:12 PM 4/8/2001 -0700, you wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gary,

The delete, delete from trash, clear sectors on disk options you made
reference to brings up something I have always been unclear about -
what is the 'security' level required/provided by WebDAV? As the
range of options you mentoned show, this is a classic "slippery
slope".  Where does it end?

I believe many activities delete and leave items in the 'trash'.
This can in some ways be viewed as a design flaw in the OS, or at
least a flaw at some level of desired security. And this is the point
- - if the desired level of security is above that provided, in
general, by the OS - are we to attempt to make up for this?

If we are to produce a 'secure' enviroment, ( not a bad thing! ), I
believe it will take a overt effort to this end. Otherwise, we will
just introduce complications here and there as we "see problems" to
no real overall gain.

But what do I know? :-)

Bruce Williams            brucewms@pacbell.net
- -----------------------------------------------
Hic locus est ubi mors gaudet succurrere vitae



-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBOtFSsHuDB3/hEB6MEQIX/gCfRzHEjpNzYJh2L3mHlK/v0QQhkIQAnRmU
VoF15I5xT4MlxmqEuDBvaY7l
=dgfy
-----END PGP SIGNATURE-----