Asp Forum - Beta2 vs. RTM mobile applications - HELP HELP! - microsoft.public.dotnet.framework.aspnet.mobile

Dan

2/21/2002 9:04:00 PM

I have a mobile applicaiton that uses a ServiceController
to stop and start services from a iPaq. I have a Beta2
version, and it works just fine. For some reason, the
new RTM version will not let me stop and start services
from a mobile client. I get the following error message:
Cannot open <servicename> on computer '<computername>'.
Same error message for any service on any system.

I even created the new solution from scratch within the
new RTM version, same code syntax, but totally rewritten
in new solution.

New RTM version locked down security a little more... so
it may be a simple config file tweak...
Got any ideas?

Special attention to bullets 1 and 3 in the "Version 1
Security Changes for the Microsoft .NET Framework
Default process identity for Web applications" document.

--> By default, Microsoft ASP.NET now runs Web
applications under an unprivileged local account. (Beta
versions of the product ran as System.)
Default security policy installed with the common
language runtime has been tightened.

--> The security policy defaults that are installed for
initial use with the .NET Framework have been changed to
reduce the permissions granted to mobile code from the
Internet or the local intranet. The new defaults reflect
a slightly more conservative set of mobile code scenarios
for the new security/functionality trade-offs of the
platform.

I tried changing the <processModel> info as the
workaround by MS stated:
<processModel userName="system"
password="autogenerate" ../>

but to no avail.

I am very concerned about this as with Beta2, I was able
to create powerful mobile applications for tech services
from a mobile device - I had permissions, and could lock
them down at the application and server levels... now,
the framework has locked me out! ALl my other mobile
applications using the ServiceController do not work, and
I can't even re-write them cause the framework has
changed!

Talk about giving someone features and then taking them
away.

Anyone have any ideas? HELP!

4 Answers

Shanku Niyogi

2/25/2002 11:57:00 PM

Dan,

As of RTM, ASP.NET applications run under the context of a local user called
ASPNET, rather than under the system account. This account is normally under
the Users group, and thus does not have administrative privileges.

Unfortunately, the administration UI also does not provide a way to give
this specific permission to an individual user.

There are some ways you can get around this:

1) The easiest: add the ASPNET to your Administrator's group. This is NOT
recommended, since it makes your server less secure.

2) If you're controlling your own service, you may be able to change the
access control (DACL) on it. Each service can have a DACL determining who
can access it. For details, see the KB at
http://support.microsoft.com/default.aspx?scid=kb;EN-....
It includes a C file that, when compiled, lets you change DACLs on a
per-service basis.

3) You can create a serviced component that runs on the server. The
component runs under a system or local admin account, so that it can access
the service controller, and allow access only to the ASPNET account.

You can learn a lot more about serviced components in the docs. Basically,
to create a serviced component on the server, you do the following:

1) Create a file with a class that inherits from the
System.EnterpriseServices.ServicedComponent class. In it, you can place
methods that you call on this class. The class also needs certain
attributes. One of these will specify that the component needs to run as a
server.
2) Build the file into a strong-named assembly. You can also copy it to the
web app's Bin directory, for step 5.
3) Install the assembly in the GAC
4) Run the Services Installation Utility to install the component.
5) From your page, using a reference to the assembly (not needed if it's in
the bin directory).
6) Once you've installed the component, you can configure it using Component
Services Manager (Programs/Administrative Tools/Component Services). This
lets you set the permissions on the component.

Here's a simple example in C# (MyComponent.cs). Of course, you'd want a more
robust set of methods for starting and stopping services.

using System.EnterpriseServices;
using System.Reflection;
using System.ServiceProcess;

[assembly: ApplicationName("MyComponent")]
[assembly: AssemblyKeyFileAttribute("MyComponent.snk")]
[assembly: ApplicationActivation(ActivationOption.Server)]

namespace MyComponent
{
public class MyServiceControl : ServicedComponent
{
public void StartService(string name)
{
ServiceController ctl = new ServiceController(name);
ctl.Start();
}

public void StopService(string name)
{
ServiceController ctl = new ServiceController(name);
ctl.Stop();
}
}
}

Here are the commands you run to build it:
sn -k MyComponent.snk (only do this once)
csc /t:library /r:System.ServiceProcess.dll
/r:System.EnterpriseServices.dll MyComponent.cs
gacutil -if MyComponent.dll
regsvcs MyComponent.dll

Here's how you use it in a page:
void Start_Click(object sender, EventArgs e)
{
MyComponent.MyServiceControl c = new MyComponent.MyServiceControl();
c.StartService("Clipbook");
}

void Stop_Click(object sender, EventArgs e)
{
MyComponent.MyServiceControl c = new MyComponent.MyServiceControl();
c.StopService("Clipbook");
}

</script>

<html><form runat="server">
<asp:Button runat="server" Text="Start" OnClick="Start_Click" />
<asp:Button runat="server" Text="Stop" OnClick="Stop_Click" />
</form>
</html>

Dan

2/26/2002 3:07:00 PM

So you're telling me "as of RTM" I either have to write
the entire thing over with windows authentication built
into the application having any users wanting this
functionality with Admin access, OR open my entire
machine so any ASP.NET user is admin.

This is not the answer I was hoping for and am very
disappointed in the lack of vision Microsoft has
instilled in moving from Beta 2 to RTM of .NET.

Shanku Niyogi

2/28/2002 12:51:00 AM

In Beta 2, every ASP.NET application ran as the local System account, and
thus had full access to a lot of resources. Effectively, it did leave the
entire machine open so that any ASP.NET user was an admin. For example, if
you were able to exploit a web site bug that could read a file on the hard
disk, you then had access to every file on the hard disk.

Not surprisingly, this mode was deemed to be relatively insecure. So the
default was changed so that every ASP.NET application runs as a known user
called ASPNET, so that site administrators can better manage access to the
web server by selectively assigning privileges to this account.

A change of a security model from one version to another is always
difficult. One of my apps, which accesses Exchange data on the server, broke
because the new model requires you to give explicit permissions to run COM
objects from an ASP.NET page. Unfortunately, security isn't a magic cookie -
it's almost impossible to have a secure server, yet have apps "just work"
without any security settings - especially one that performs some pretty
privileged operations, as yours does.

If you'd like to get the Beta 2 behavior back, you can just edit the
<processModel> tag in machine.config, and change the userName attribute from
"Machine" to "System". But this is probably not the best way to go long
term.

By moving the code that starts and stops services to a serviced component,
as shown in the previous example, you can most quickly get your app back up
and running, because it requires no other authentication work to be done by
default. Then, you can administer access to your app by changing settings on
the component.

If you have any further questions about this, please feel free to contact me
by email (shankun@microsoft.com).

Thanks,
Shanku

--
This posting is provided "AS IS" with no warranties, and confers no rights.

"Dan" <dang@microendeavors.com> wrote in message
news:843e01c1bece$f7306950$36ef2ecf@tkmsftngxa12...
> So you're telling me "as of RTM" I either have to write
> the entire thing over with windows authentication built
> into the application having any users wanting this
> functionality with Admin access, OR open my entire
> machine so any ASP.NET user is admin.
>
> This is not the answer I was hoping for and am very
> disappointed in the lack of vision Microsoft has
> instilled in moving from Beta 2 to RTM of .NET.

Paul Gower

3/25/2002 10:11:00 PM

microsoft.public.dotnet.framework.aspnet.mobile

Beta2 vs. RTM mobile applications - HELP HELP!

Dan

Shanku Niyogi

Dan

Shanku Niyogi

Paul Gower

x Login to ForumsZone