Setting up access rights for Semaphore?
I am assuming that once a semaphore is created by a process, it will be available to any process / user.
Is it possible to set access restrictions for a particular semaphore so that it can only be accessed by certain processes / users or only certain processes can release the semaphore.
I see some problems if we create a semaphore that is available to all processes. Eg: The dummy process can read the semaphore and release the lock if desired, giving a false signal to the actual process that is actually waiting for the semaphore lock.
All these questions come up as I get very strange output with the following piece of code:
use Win32::Semaphore;
$sem = Win32::Semaphore->new(0, 1,"reliance2692")
or print "Can't create semaphore\n";
$sem = Win32::Semaphore->open("reliance2692")
or print "Can't open semaphore\n";
print "Semaphore:" . $sem . "\n";
By running the above program, I get the following output
Can't create semaphore Can't open semaphore
The output shows that its failed to create a semaphore and even failed to open a semaphore. semaphore creation might fail if a semaphore already exists with the given name. I don't understand why opening the semaphore failed.
Can anyone elaborate on a scenario that dumps both semaphore creation and semaphore opening.
source to share
From Win32 :: Semaphore pod
$semaphore = Win32::Semaphore->new($initial, $maximum, [$name])
Constructor for a new semaphore object. $ initial is the starting counter and $ maximum is the maximum value for the semaphore. If $ name is omitted or undef, an unnamed semaphore is created.
If $ name means an existing semaphore object, then $ initial and $ maximum are ignored and the object is opened. If it does, it will
$^E
be set to 183 (ERROR_ALREADY_EXISTS
).
If I read this correctly, if your call Win32::Semaphore->new
refers to an existing semaphore, then the call new
will open the semaphore as well, and the subsequent call open
will be redundant (it's not clear from me what should happen if you open a sempahore that is already open).
Perhaps you could go through the code by checking the value $sem
, as well $!
, and $^E
at each step.
Complementary answer: Windows API has methods for setting semaphore access control, but
- they do not appear in the Perl module
Win32::Semaphore
- Access control cannot be set unless it was allowed by another process that created the semaphore
I don't know if you have any good options for this problem. Can you change the process that creates the semaphore to loosen access restrictions? Ask the author to Win32::Semaphore
update his module? Try to fix it Win32::Semaphore
yourself?
source to share
Win32::Semaphore->new
calls a Windows API function CreateSemaphore
and gets the default security descriptor for the process, which usually means that processes running as the same user as your script can have full access, whereas processes running as other accounts cannot. So, to begin with, your assumption is wrong.
The name you choose in your Perl code is passed directly to the API function, so it obeys the same namespace rules as all other Win32 Kernel Objects.
Win32 :: Semaphore does not provide an interface for specifying access restrictions. Even so, Windows does not grant permissions to every process. Permissions are attached to the user, not the process.
If you get an "access denied" from new
, it means that another program is running, which has chosen the same name for something else - perhaps a different semaphore, or maybe something else, such as an event or a mutex - and this process runs as another user.
If you are getting "access denied" from open
, then in addition to capabilities, it new
may be that another process has already opened a semaphore with the same name, but has not granted full permissions to other users. Win32::Semaphore->open
asks for SEMAPHORE_ALL_ACCESS
permission .
If the semaphore has already been opened by a process running as the same user, then you should not get "access denied". In this case new
, neither open
should nor should work, although it $^E
may contain 183 ( ERROR_ALREADY_EXISTS
).
source to share
For the record, I'm the author of Win32 :: Semaphore . As mobrule and Rob explained, Windows security is user / group based. It is not possible to have a semaphore that only certain processes can access. If any process owned by a user can access the semaphore, then any process of that user can access that semaphore.
Typically, default access only allows the current user to access the semaphore. No one has ever asked for the ability of Win32 :: Semaphore to specify a security descriptor other than the default, and the associated APIs are non-trivial. If anyone has created a module to manage the SECURITY_ATTRIBUTES structure, I would be happy to add support for this to Win32 :: Semaphore and its related IPC modules. Win32-Security doesn't seem to be that module, although it might be a start.
If you need a semaphore to work with multiple users, your only solution right now is to create a semaphore outside Win32 :: Semaphore by passing in the appropriate SECURITY_ATTRIBUTES pointer. You can do this with a small auxiliary program written in C, or using the Inline :: the C . (Remember, once created, the semaphore exists as long as any process has an open handle, so your helper must keep the semaphore handle open until you call Win32::Semaphore->open
on it.)
source to share