BUG – Permissions removed from an application root folder
Last post Apr 23, 2012 01:08 PM by GrZeCh
May 08, 2011 11:57 AM|LINK
After publishing of DotNetNuke application all permissions inherited from the parent folder are removed by WebMatrix from the application root folder.
Even the permissions for Administrators and SYSTEM ! Which means that even a Windows Administrator cannot navigate through the physical directory structure of the website !
I think that all inherited permissions from the parent folder should not be modified by WebMatrix.
It should be fixed ASAP.
May 08, 2011 05:06 PM|LINK
I can confirm this issue. In my opinion WebMatrix should not change any permissions in any case. WebMatrix publishing feature is intended to be used with hosting companies which are for sure setting proper permissions during their clients website and directory
structure creation so there is no need to modify them because it will cause more problems than advantages. I'm wondering why this permissions are even changed? What hosting company is allowing to do that?
May 09, 2011 11:18 AM|LINK
May 09, 2011 11:25 AM|LINK
DotNetNuke installation package comes with the following Manifest.xml file :
<iisapp path="DotNetNuke" />
<setAcl path="DotNetNuke" setAclAccess="Modify" />
So it seems that it is clearly
Webmatrix bug (requested Acl is “Modify” not “Read&Write”).
Edit : see also this thread :
May 09, 2011 06:53 PM|LINK
Hi Maciej and GrZeCh,
I will certainly look into these issues with permissions being removed (or the other thread about the wrong permissions being set) and post-back with an explanation or plan of action - but generally speaking it is considered a feature of Web Deploy publishing
that the applications can determine ACLs that they will require for the application pool identity and that they get set on the destination site to ensure the application will work - this is a plus from FTP publishing, where these ACLs otherwise need to be
adjusted manually by the user. The ACLs are defined by the application owners as requirements for their application working.
The server administrator can choose not to allow these ACLs to be changed (particularly on the root) by giving the publishing user limited ACLs (such as Modify rather than Full Control) - but I believe most of those in the hosting gallery do give Full Control
to make sure publishing of applications with root-level setAcls still works without error. Server owners can also choose to deny any setAcl operation by Web Deploy, or for specific users, by using Delegation rules (this is akin to the suggested changePermissions=false
setting, and is fully controlled by the server admin) - but as most OSS applications in the gallery use setAcls, this limits what applications can be published without error.
May 09, 2011 07:48 PM|LINK
can you give us some sample setAcl example which will allow to install DNN but not allow to remove existing permissions? I was trying "Read, Modify" but WebMatrix is only allowing to publish when there is "*" or "Read, Write" set. Maybe instead of changePermissions
property there could be something like "allowPublishingWihoutSettingPermissions" (I know it's too long :) but you know what I mean) ?
Do you know how many hosting companies allow WebMatrix to change permissions? I still think that if this feature is intended to be used with professional hosting providers then all proper permissions should be already set when customers are creating their
websites in hosting control panels.
May 09, 2011 09:33 PM|LINK
Moreover, in some cases the professional hosting company has to set some special permissions, which should never be removed. For instance, because
of well-known bug in ASP.NET 2.0 running under Medium Trust whereby a security exception is raised in mscorlib 184.108.40.206 when calling CreateDirectory method if the application pool identity has no rights defined in one of the parent directories. Note that CreateDirectory
is used by DotNetNuke installer in order to check the permissions setting. As a workaround for this bug in ASP.NET 2.0 (fixed in ASP.NET 4.0), read permission for app pool identity has to be set in the parent folder of the application root folder.
So let me to repeat : the permissions already set in the application root folder (inherited or not from its parent folder) should NEVER be removed.
Moreover : the inheritance of these permissions should not be broken.
May 10, 2011 02:00 AM|LINK
I have been trying to reproduce this scenario, where the permissions are removed, but am not seeing the behavior you describe where SYSTEM or Administrator accounts are removed. Could either of you please provide some additional information about the steps
or settings you are using?
I agree that the removal of the existing ACLs is a serious issue, but it is not being experienced by everyone; I'd like to determine why the two of you are seeing this behavior as there may be a simple explanation or setting that we're missing.
GrZeCh - for the setAcl example are you referring to a delegation rule format or the user ACLs on the directory? For the directory ACLs, you can do "modify" only on the parent directory of the highest-level setAcl. For example, if there are root setAcls
for the application, the user would need either full control on the root of the site, or modify permission on the parent directory to the site root. A delegation rule will allow or deny the use of the provider, but not selectively deny one provider while
allowing the rest of a WebMatrix publish (which includes other providers) to work. This was considered something the client could just choose to omit if they wanted. We can consider this as a potential feature for the next version (to add the ability within
WebMatrix to exclude setAcls when publishing) - but I fear this will not be seen as a common use case for the WebMatrix user given that our Hosting Gallery recommended hosting providers do allow these setAcl operations.
For other clients, such as the web deploy cmd line, it is possible to easily just remove the setAcl entries from the manifest on the client or to skip them to get around this type of problem. Would you be interested in learning how to do command line publishing
as an alternative?
Also - for the other thread - I'll try to post an update there tomorrow. It is a bug, and I can give you a workaround that will at least avoid manual ACL updates for future publishes.
May 10, 2011 06:27 AM|LINK
First at all : an issue observed by one or two persons is always an issue.
Here are my setting :
Windows Web Server 2008 R2 + WebSitePanel control panel.
ASP.NET running in Medium Trust.
Fully qualified path to the root of the application: ‘D:\HostingSpaces\toto\titi.com\wwwroot\’
Permissions set by server Admin (before publish):
Full control for Administrators and SYSTEM on ‘D:\’
Read permission for NETWORK SERVICE on ‘D:\HostingSpaces’
(workaround for ‘CreateDirectory’ ASP.NET 2.0 bug)
Permissions set by customer using WebsitePanel (before publish):
Modify permission for FTP user account on ‘D:\HostingSpaces\toto\’
Modify permission for NETWORK SERVICE on ‘D:\HostingSpaces\toto\titi.com\wwwroot\’
Modify permission for anonymous IIS account belonging to IIS_IUSRS on ‘D:\HostingSpaces\toto\titi.com\wwwroot\’
Application Pool identity is NETWORK SERVICE, ASP.NET is set to 2.0 Integrated Pipeline
These settings resume in the following effective permissions on the ‘D:\HostingSpaces\toto\titi.com\wwwroot\’ folder :
Full control : SYSTEM (inherited), Administrators (inherited)
Modify : SYSTEM (inherited), Administrators (inherited), NS, account belonging to IIS_IUSRS, FTP account (inherited)
Read & execute : SYSTEM (inherited), Administrators (inherited), NS, account belonging to IIS_IUSRS, FTP account (inherited)
List folder contents : SYSTEM (inherited), Administrators (inherited), account belonging to IIS_IUSRS, FTP account (inherited)
Read : SYSTEM (inherited), Administrators (inherited), NS (inherited), account belonging to IIS_IUSRS, FTP account (inherited)
Write : SYSTEM (inherited), Administrators (inherited), NS, account belonging to IIS_IUSRS, FTP account (inherited)
Web Matrix settings :
DotNetNule installed and configured with SQL Server database (not SQL Express). Running on localhost without any issue.
Publish from Web Matrix : all files and database, publish successful.
Effective permissions on ‘D:\HostingSpaces\toto\titi.com\wwwroot\’ after publish:
Full control :
Modify : account belonging to IIS_IUSRS
Read & execute : account belonging to IIS_IUSRS
List folder contents : account belonging to IIS_IUSRS
Read : NS (not inherited ! - overwritten), account belonging to IIS_IUSRS
Write : NS, account belonging to IIS_IUSRS
NOTE : I don’t observe described issue when publishing Web Matrix website created from Web Matrix template.
May 10, 2011 10:35 PM|LINK
Thank you for the additional details.
Please let me apologize for my previous wording - I was not trying to imply that this is not a major issue; we are very concerned by it and we really appreciate your taking the time to let us know about it! The fact that you are experiencing it where we
are not is worrisome as it means we may be missing an important setting or detail and under-testing it.
We're looking at it to see if we can reproduce these conditions, based on the information you've provided, but we may ask for other specific details if still unable to get the same behavior.
Thank you for your help on this.