Permissions

  • Thread starter Thread starter Alvin Bruney [MVP]
  • Start date Start date
A

Alvin Bruney [MVP]

Hi group, its been a while...

I encountered a nasty permissions error that I was unable to solve and
eventually had a workaround but it has been at the back of my mind for a
while. Any takers?

Webpage fires a thread. Thread invokes a perl script via process.Start().
The script queries the database and tries to write a file on a remote
computer using a shared path.
Access denied errors. From my end, I used impersonation and I can tell that
the impersoned identity is correct up until the script is invoked. From
there, I don't really know
what happens. The guy who wrote the script doesn't know how to display the
process under which the account is running. Not really sure if this is even
possible
with perlscript. My question: Is there anything funky going on with threads,
shares, and the process invoke that may cause identities to be
dropped/discarded/ignored in this manner?
(Permissions to the system account failed by the way.)

--
Regards,
Alvin Bruney

Coming this month
The Microsoft Office Web Components Black Book with .NET
http://tinyurl.com/27cok
 
Alvin,

I don't believe that new managed Threads have their principal set, so
when you run the thread, it runs under the ASPNET user account.

In .NET 2.0, this behavior is changed. New threads created in a managed
context will inherit the identity of the creator of the thread (even thread
pool threads).

In 1.1, the identity is not carried over. If anything, when the Thread
is created, you should set the CurrentPrincipal property with the principal
that created with the thread. Either that, or call the SetAppDomainPolicy
method on the AppDomain the thread will be created in, and set it to
WindowsPrincipal, so that it uses the current windows user and sets that to
the principal for the thread.

Hope this helps.
 
Processes spawned that way inherit the process identity of the parent
process, never the identity of the thread that spawned the process.
..NET v2.0 will provide an option to change this behavior (it uses the
CreateProcessAs API), that makes it possible to create a process running
with alternate credentials.

Willy.
 
Nicholas Paldino said:
Alvin,

I don't believe that new managed Threads have their principal set, so
when you run the thread, it runs under the ASPNET user account.

In .NET 2.0, this behavior is changed. New threads created in a
managed context will inherit the identity of the creator of the thread
(even thread pool threads).
Click to expand...

This won't help you even on v2.0.
The process inherits the identity of the parent process, never the identity
of the calling thread.
What's changed in .NET v2.0 is that Process.Start now encapsulates Win32 API
CreateProcessAsUser, and you can set the spawned process credentials through
the ProcessStartInfo class.

Willy.
 
Processes spawned that way inherit the process identity of the parent
process, never the identity of the thread that spawned the process.
Click to expand...
Ok. But the parent was set to impersonate from the web.config file and not
thru code impersonation, so the account (parent of the thread)should have
been set to the impersonated account right? Or are you
saying that even with impersonation, the account was the asp.net account. I
know this to be incorrect because a display of the principle showed the
impersonated account for the main app.

Somehow, the thread must have defaulted back to the aspnet account and not
the impersonated account. There was no asp.net account on the NAS server
where the file was to be written by the way but the impersonated account
existed.
Could this be a bug?

--
Regards,
Alvin Bruney

Coming this month
The Microsoft Office Web Components Black Book with .NET
http://tinyurl.com/27cok
 
Alvin Bruney said:
Ok. But the parent was set to impersonate from the web.config file and not
thru code impersonation, so the account (parent of the thread)should have
been set to the impersonated account right? Or are you
saying that even with impersonation, the account was the asp.net account.
I know this to be incorrect because a display of the principle showed the
impersonated account for the main app.

Somehow, the thread must have defaulted back to the aspnet account and not
the impersonated account. There was no asp.net account on the NAS server
where the file was to be written by the way but the impersonated account
existed.
Could this be a bug?
Click to expand...
No, it's not a bug.
Your asp worker process identity is taken from the web.config file
<processmodel element - userName and password attributes.
Impersonation only indicates what thread identity should be taken for an
unauthenticated client when impersonating, but as I said before the process
identity is used when spawning another process.

Willy.
 
Back
Top