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.
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?
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.
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.
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 2.0.0.0 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.
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.
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.
MaciejR
26 Posts
BUG – Permissions removed from an application root folder
May 08, 2011 11:57 AM|LINK
Hello,
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.
Best Regards,
Maciej
DotNetNuke permissions
GrZeCh
64 Posts
Re: BUG – Permissions removed from an application root folder
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?
GrZeCh
64 Posts
Re: BUG – Permissions removed from an application root folder
May 09, 2011 11:18 AM|LINK
MaciejR
26 Posts
Re: BUG – Permissions removed from an application root folder
May 09, 2011 11:25 AM|LINK
DotNetNuke installation package comes with the following Manifest.xml file :
MSDeploy.iisApp>
<iisapp path="DotNetNuke" />
<setAcl path="DotNetNuke" setAclAccess="Modify" />
</MSDeploy.iisApp>
So it seems that it is clearly Webmatrix bug (requested Acl is “Modify” not “Read&Write”).
Edit : see also this thread : http://forums.iis.net/t/1178034.aspx
Best Regards,
Maciej
krolson
350 Posts
Microsoft
Re: BUG – Permissions removed from an application root folder
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.
Thanks,
Kristina
GrZeCh
64 Posts
Re: BUG – Permissions removed from an application root folder
May 09, 2011 07:48 PM|LINK
Hello,
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.
MaciejR
26 Posts
Re: BUG – Permissions removed from an application root folder
May 09, 2011 09:33 PM|LINK
Hello,
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 2.0.0.0 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.
Best Regards,
Maciej
krolson
350 Posts
Microsoft
Re: BUG – Permissions removed from an application root folder
May 10, 2011 02:00 AM|LINK
Hi Maciej and GrZeCh,
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.
Thanks,
Kristina
MaciejR
26 Posts
Re: BUG – Permissions removed from an application root folder
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.
Best Regards,
Maciej
krolson
350 Posts
Microsoft
Re: BUG – Permissions removed from an application root folder
May 10, 2011 10:35 PM|LINK
Hello Maciej,
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.
-Kristina