Hi all, because of the discussion in the [EMAIL PROTECTED] list, checkCredentials seems to be done not in the right way in Slide. I plan to fix it in the following way: Add a new flag to the SlideToken which shows if a credentials check has allready been done. Add credentials check to the HTTP Methods in the Webdav tier After a successfull credentials check the flag in the SildeToken will be set to show that a credentials check has already been done. The helpers will just do a credentials check if the check not have been done before.
The result will be, if the client request comes via the HTTP Method of the webdav layer, the credentials will just be checked by the HTTP Methods one time instead of 8-10 times currently. Comments are welcome regards Eckehard -----Original Message----- From: Hermann, Eckehard Sent: Tuesday, August 13, 2002 3:45 PM To: 'Stefan Eissing' Cc: '[EMAIL PROTECTED]' Subject: RE: [ACL] Aggregation of Predefined Privileges o.k., I understand, thank you, regards Eckehard -----Original Message----- From: Stefan Eissing [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 13, 2002 2:53 PM To: Hermann, Eckehard Cc: '[EMAIL PROTECTED]' Subject: Re: [ACL] Aggregation of Predefined Privileges Am Dienstag den, 13. August 2002, um 14:44, schrieb Hermann, Eckehard: > > > Am Dienstag den, 13. August 2002, um 14:02, schrieb Hermann, Eckehard: > >> [...] >> Am Dienstag den, 13. August 2002, um 13:01, schrieb Hermann, Eckehard: >> >>> [...] >>> More clear >>> would be if dav:write contains dav:read. So if a user has the >>> privilege for >>> doing updates, he also has the privilege for reading the resource. >> >> < You might have write acess to an ftp upload directory, but no read >> < access to that directory. It's not a common use case, but there is >> < a use case. >> >> I currently thinking about the privilege to read locks (concret >> for fixing >> the the implementation in slide). A user who has the privileg to >> read locks >> e.g. via the propfind method should have read privilege. But to >> update a >> resource the user must be able to read the locks as well. So if >> read locks >> contains read and the webdav server implements locking, for doing >> updates >> the write privilege would not be enough. In each case read would be >> necessary. If read-locks does not contain read, the user is able >> to have the >> read-lock privilege but not read, so he is able to read parts of a >> resource >> without having read privilege which sound a bit strange to me. > > < Hmm, without knowing the internals of Slide, I may not understand the > < need for DAV:read-lock. It sounds pretty superflouous to me. > < > < case a) the client locks a resource -> no need for DAV:read-lock > < case b) the client modifies the resource and provides lock token > < in If: header -> no need > < case c) the client unlocks a resource with If: header -> no need > < case d) the client wants to discover locks on a resource he is not > < allowed to read -> should be a 403 > < > < So, maybe you have to describe in more detail what purpose > DAV:read-lock > < should server here. > > <//Stefan > > I would not like to have a DAV:read-lock privilege in the > standard. What I > try to explain is that a DAV:write implicit must be able to read > the locks > or read the acls (for the check if the user has the privilege to > execute the > write). Here you get it wrong. The privileges control what the user can do and not what the server software can do. In most implementation the tests for locked resources will not check the current user privileges. Same for acls: the user might be forbidden to read the acl, but the server will always be able to check the acl. The WebDAV ACL protocol specifies the privileges for operations on the protocol layer. How your software ist structured and how the security control between different modules is handled is not part of WebDAV ACL. As you found out, it will be messy, if you mix those two layers. //Stefan > So a DAV:write implicit contains e.g. DAV:read-acl or the privilege > to read parts of a resource like e.g. the locks. The consquence > should be > the definition in the standard of DAV:write should contain DAV:read and > DAV:read-acl. If not, a write would (independent of the implementation) > physically not be possible if the user does not have the read and > read-acl > privileg or it does forbidden things like reading the acls. So a write > privileg is not able to exist for itself allown. > > regards Eckehard > >>> Additionally I also do not understand why the write-acl privilege >>> must not >>> contain all privileges, because the fact that a user is able to >>> change his >>> own privileges all privileges are implicit with the write-acl >>> privilege >>> independent if the standard does define it or not. >> >> < For the same reason, root users on UNIX would be displayed file >> < attributes >> < "rwx" for all files because he could set "rwx" on all files. >> Still, I >> < consider it useful to set a file to readonly... >> >> That is true, but in this case the write-acl permission would be an >> administrative feature. >> >> < //Stefan >> >>> regards >>> Eckehard >>> >>> Eckehard Hermann >>> Research & Development >>> Software AG >>> Uhlandstrasse 12 >>> D-64297 Darmstadt >>> Germany >>> >>> mailto:[EMAIL PROTECTED] >>> phone: +49-6151-921465 >>> fax: +49-6151-921609 >>> >>> _______________________________________________ >>> acl mailing list >>> [EMAIL PROTECTED] >>> http://mailman.webdav.org/mailman/listinfo/acl >>> >> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
