Re: File permissions vary based on access method problem
- From: Daniel Stratton <DanielStratton@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 1 May 2006 23:10:02 -0700
Thanks David for such a lengthy and informative post, it has certainly given
me a lot to think about. And I can certainly appreciate why such things
aren't done out of the box these days, but it is troublesome to figure out
for one's self :)
I do have a few questions for you, if you have the chance to respond.
- You mention WebDAV. A quick look at my test machine away from the office
is only Windows XP Pro, and doesn't mention WebDAV at all in the Add/Remove
components for IIS. Is this something only works on Server editions of XP?
Some clients may not be running a true server, as they are a very small
business.
- Primarily, only a single user should be able to add files to the system.
Can I lock down WebDAV so that only a single user does this? However, it may
be required for multiple people to be able to write to existing files.
Mostly, however, I want them all read only. My impression from your post is
that this is possible?
- In essence, I've been asked to develop something where there is a central
list of files (but not necessarily browseable, things like XLS, DOC, PPT and
so on), which are accessed through clickable browser links, and preferably
avoiding a common mapped drive as people need to be able to access this from
home. In most instances, it's read only, but in a select few, it would be
with write permissions. Without WebDAV, the read part certainly works. Will
using WebDAV allow this write capability?
- If I enable WebDAV, will users be able to poke and prod into it via means
other than the developed ASP site? Because that would not be a good thing,
really.
Thanks for your information already, it's certainly been an eye opener and
looks to give me a few nights of heavy reading ahead of me :)
Regards,
Daniel Stratton
"David Wang [Msft]" wrote:
http://blogs.msdn.com/david.wang/archive/2005/08/20/Why_can_I_upload_a_file_without_IIS_Write_Permission.aspx.
The issue is that "different access methods" have different security
configurations. You do not have comparable configuration of security for
each access method, hence behavior can appear different.
You always need to be clear about:
1. What user identity is performing the action
2. Through what protocol is the action performed
3. Does the resource allow that user identity to perform that action through
that protocol
Things no longer "automagically" work on Windows anymore, especially from
Windows Server 2003 onwards, because history has shown that when we make
things "automagically work", hackers take advantage of it more than normal
users stumbling around and running into that functionality. The result of
the security lockdown is that users have to know more about what they are
doing. Now, how users figure out what they are doing, I have no idea. ;-)
When you access resources via H: or file://, it is treated as access through
a UNC share as your user identity, which means that restrictive merge of
ACLs on the UNC share and NTFS ACLs on the specific resource as well as your
user identity govern access.
When you access resources via http:// , it is treated as access through
HTTP. By default, HTTP is a read-only protocol. "Writes" can happen only if
you write and run custom code on top of HTTP, or you enable WebDAV. In all
cases, the authentication protocol negotiated between the client and server
determines the user identity making the read/write operation, and that user
identity has to have NTFS ACLs on the resource to perform the read/write
operation in addition to having the "logical" ability to make the "Write".
In other words:
- if you set the Read-Only attribute on a file and enable WebDAV write, you
still cannot write to the file either through http:// or H: or file://
because the Read-Only attribute disallows all modifications.
- if you do not enable WebDAV and have no other custom code which performs a
logical HTTP write operation, then you cannot write via http:// while user
credentials govern whether H: or file:// can write to the resource (assuming
the resource allows modifications).
--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Daniel Stratton" <Daniel Stratton@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:7E60E96C-27CD-46DE-A3AA-1AEBA056D1C1@xxxxxxxxxxxxxxxx
I'm currently maintaining an intranet ASP based product for a small
business,
and I have run into an odd problem.
I have a directory which is full of documents that need to be accessed via
a
central website, both internally from the office, and externally from
home.
The data sits on the server (Windows 2003 SBS) at C:\Data\Platform. This
directory is shared on the office intranet as H:, and a Virtual Directory
(VD1) is setup on the website that points to this location as well. The
virtual directory has NTFS access for Admins, Everyone, IIS_WPG,
IWAM_MACHINE
and IUSR_MACHINE. It also has Read, Write, and Directory Browse
permissions
from within IIS.
C:\Data\Platform is marked as full control for Admins, Everyone, IIS_WPG,
IWAM_MACHINE and IUSR_MACHINE. The share is set to read, write and modify
for all. The file that is trying to be accessed (records.xls) is not
marked
as read only.
If a user tries to access the file through the virtual directory (ie a
http:// link to VD1/records.xls), the file opens in read only mode. If a
user tries to access through the intranet (ie a file:// link to
H:/records.xls) then the file is opened in write mode.
Both anonymous and integrated windows access are enabled, with IP
restrictions of 192.168.0.x and 127.0.0.1. But this issue occurs within
the
office as well, so that only files that are accessed through H: are
openable
for write mode. Something seems to be restricting it to read only mode
through the use of the virtual directory.
Most documents we only want to be read only, but some of them we do want
to
be able to write to (communal time sheets for instance). External write
access is desired to allow the rest of the office to work more flexibly.
All
clients are latest patched versions of IE6.
How do I make it so that the file is accessible for writing through the
Virtual Directory?
Thanks in advance for any suggestions.
- References:
- Re: File permissions vary based on access method problem
- From: David Wang [Msft]
- Re: File permissions vary based on access method problem
- Prev by Date: Re: File permissions vary based on access method problem
- Next by Date: Re: Muliple Websites on Mutliple IP address with certicles [SSL]
- Previous by thread: Re: File permissions vary based on access method problem
- Next by thread: Re: File permissions vary based on access method problem
- Index(es):
Relevant Pages
|
