Need help with named mutex shared between asp.net and .net win app.

  • Thread starter Thread starter Ken Varn
  • Start date Start date
K

Ken Varn

I have a named mutex object that is accessed by both an asp.net application
and a Windows executable .net application. The Windows executable runs
under the administrator logon, while the asp.net application runs under the
standard asp.net user account. The problem relates to permissions on
creation of the mutex. If the asp.net application creates the mutex, the
executable cannot access it (access denied error). Likewise, if the
executable creates the named mutex, then the asp.net application cannot
access it.

I know that in MFC you can set a security descriptor for the CMutex object
so that it is created with a set security descriptor level. How is this
done in .NET using .NET mutex object?

--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------
 
pick one, maybe the asp.net account. and set it to impersonate the same
account the windows app uses. better yet, create a single user account and
have both these applications impersonate this user to create and access the
mutex.
 
Sorry, this is not an area I am real familiar with in .NET. I know that in
MFC, I cam create a mutex object with SECURITY_ATTRIBUTES and thus indicate
the security level of the mutex. I am not sure how to do the same thing in
..NET. All I want to do is grant all processes access to this mutex without
doing impersonation. Is this possible?

--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------
Alvin Bruney said:
pick one, maybe the asp.net account. and set it to impersonate the same
account the windows app uses. better yet, create a single user account and
have both these applications impersonate this user to create and access the
mutex.
Click to expand...
 
Bellow is the snippet of the code that either opens already created mutex or
creates one that can be open by any process.
The trick here is to set right security attributes for newly created mutex.
Some of the functions used are from native Win32 API - you will need to map
them to your program.
Let me know if you have problems doing so.


private void PrivateConstruct(bool initiallyOwned, string name, out
bool createdNew)
{
// It's faster to first try OpenMutex
int hMutex = OpenMutex(SYNCHRONIZE, 1, ToSystemMutexName(name));
createdNew = false;
if (hMutex == 0)
{
SECURITY_ATTRIBUTES sa = new SECURITY_ATTRIBUTES();
sa.nLength =
System.Runtime.InteropServices.Marshal.SizeOf(sa);
sa.bInheritHandle = 1;
sa.lpSecurityDescriptor = 0;

int securityDescriptorSize = 0; // dummy
int result =
ConvertStringSecurityDescriptorToSecurityDescriptor(
"D:(A;NP;0x001f0001;;;WD)", // Grant
MUTEX_ALL_ACCESS to Everyone
SDDL_REVISION_1,
ref sa.lpSecurityDescriptor,
ref securityDescriptorSize);
if (result == 0)
{
throw new Exception("Failure while creating security
descriptor for new mutex");
}

hMutex = CreateMutex(ref sa, initiallyOwned ? 1 : 0,
ToSystemMutexName(name));
createdNew = (Marshal.GetLastWin32Error() !=
ERROR_ALREADY_EXISTS);
LocalFree(sa.lpSecurityDescriptor);

if (hMutex == 0)
{
// If we get here, some sort of unrecoverable error has
presumably occurred.
// However, we will try one last time, in case it was
merely some sort of race condition.
// Note that I do not believe that there is any opening
for a race condition in the above code.
// Nevertheless, we have nothing to lose by giving it
one last try.
hMutex = OpenMutex(SYNCHRONIZE, 1,
ToSystemMutexName(name));
createdNew = false;
if (hMutex == 0)
{
throw new Exception("Unable to create or open
mutex.");
}
}
}

Handle = (IntPtr)hMutex;
}


Sergiy Mesropyan
www.anticipatingminds.com
 
It sounds as if there is no way to do this in native .NET code without using
pinvoke. Seems odd that this functionality was not included in the Mutex
object since this is part of the Win32 Mutex capability.

My module is in managed C++, but I was using the .NET version of Mutex just
to limit the amount of mixed code that I was using. I guess I can go back
and use the Win32 calls directory in my managed C++ code. It is a little
frustrating when some of these basic Win32 features are not included in
managed classes that appear to mimic the Win32 functionality.

Also, as a side note, I can't even understand why the ASP.NET application
would prevent the Windows application from accessing the mutex that it
created since the windows app was running as an administrator level.


--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------
Sergiy Mesropyan said:
Bellow is the snippet of the code that either opens already created mutex or
creates one that can be open by any process.
The trick here is to set right security attributes for newly created mutex.
Some of the functions used are from native Win32 API - you will need to map
them to your program.
Let me know if you have problems doing so.


private void PrivateConstruct(bool initiallyOwned, string name, out
bool createdNew)
{
// It's faster to first try OpenMutex
int hMutex = OpenMutex(SYNCHRONIZE, 1, ToSystemMutexName(name));
createdNew = false;
if (hMutex == 0)
{
SECURITY_ATTRIBUTES sa = new SECURITY_ATTRIBUTES();
sa.nLength =
System.Runtime.InteropServices.Marshal.SizeOf(sa);
sa.bInheritHandle = 1;
sa.lpSecurityDescriptor = 0;

int securityDescriptorSize = 0; // dummy
int result =
ConvertStringSecurityDescriptorToSecurityDescriptor(
"D:(A;NP;0x001f0001;;;WD)", // Grant
MUTEX_ALL_ACCESS to Everyone
SDDL_REVISION_1,
ref sa.lpSecurityDescriptor,
ref securityDescriptorSize);
if (result == 0)
{
throw new Exception("Failure while creating security
descriptor for new mutex");
}

hMutex = CreateMutex(ref sa, initiallyOwned ? 1 : 0,
ToSystemMutexName(name));
createdNew = (Marshal.GetLastWin32Error() !=
ERROR_ALREADY_EXISTS);
LocalFree(sa.lpSecurityDescriptor);

if (hMutex == 0)
{
// If we get here, some sort of unrecoverable error has
presumably occurred.
// However, we will try one last time, in case it was
merely some sort of race condition.
// Note that I do not believe that there is any opening
for a race condition in the above code.
// Nevertheless, we have nothing to lose by giving it
one last try.
hMutex = OpenMutex(SYNCHRONIZE, 1,
ToSystemMutexName(name));
createdNew = false;
if (hMutex == 0)
{
throw new Exception("Unable to create or open
mutex.");
}
}
}

Handle = (IntPtr)hMutex;
}


Sergiy Mesropyan
www.anticipatingminds.com
Click to expand...
 
There is basically no support for Windows security in .NET 1.x except for
the WindowsIdentity and WindowsPrincipal classes. Thus, any time you need
to do something with SDs, DACLs, ACEs, SIDs and tokens, you end up doing
interop and pinvoke. Thus the proliferation of wrappers to fill the gap.

The Whidbey story is better though. Also greatly improved is crypto support
which needed a lot of help too.

Joe K.

Ken Varn said:
It sounds as if there is no way to do this in native .NET code without using
pinvoke. Seems odd that this functionality was not included in the Mutex
object since this is part of the Win32 Mutex capability.

My module is in managed C++, but I was using the .NET version of Mutex just
to limit the amount of mixed code that I was using. I guess I can go back
and use the Win32 calls directory in my managed C++ code. It is a little
frustrating when some of these basic Win32 features are not included in
managed classes that appear to mimic the Win32 functionality.

Also, as a side note, I can't even understand why the ASP.NET application
would prevent the Windows application from accessing the mutex that it
created since the windows app was running as an administrator level.


--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------
Sergiy Mesropyan said:
Bellow is the snippet of the code that either opens already created
Click to expand...
mutex
Click to expand...
 
Back
Top