Subject: Re: [offlist] WebDAV Delete post (Flavors of DELETE)

From: Gary Gershon <[email-masked]>
Date: Tue, 10 Apr 2001 09:54:53 -0400

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
[email-masked]

- -----------------------------------------------

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-----