Clever Geek Handbook

CreateSemaphoreEx vs Access Mask security attribute

The CreateSemaphoreEx API on Windows platform has the following parameters:

LPSECURITY_ATTRIBUTES lpSemaphoreAttributes and DWORD dwDesiredAccess

I understand that both of them are for access control, however I am not sure about their relationship and the differences between them. For example, if I set dwDesiredAccess to SYNCHRONIZE, but I create a security attribute with an empty DACL (that is, no access at all), then how does this work together? If someone can share information about the purpose of these parameters and how they interact with each other, that would be great.

Thank.

+3


source to share


1 answer


If the object already exists:

  • The parameter is lpSemaphoreAttributes.lpSecurityDescriptor

    ignored.

  • The parameter dwDesiredAccess

    determines what access rights are passed to the new handle returned by the function. If these access rights are incompatible with the security permissions on the object, the call will end with ERROR_ACCESS_DENIED

    .

If the object doesn't exist yet:

  • The parameter lpSemaphoreAttributes.lpSecurityDescriptor

    determines which security permissions are assigned to the newly created object. If no security descriptor is specified, the default permissions are used.

  • The parameter dwDesiredAccess

    determines what access rights are passed to the new handle returned by the function. These rights are not limited by security permissions on the newly created object. Conceptually, an object handle is opened before new permissions are applied.

So, if you specify a DACL with an empty ACL (thus implicitly denying access to everyone), then the only way to access this object is through the handle created with the object, or a duplicate of this handle. There is no way to reopen an object, even from the same process, unless you change the permissions to allow you to do so.



Note that different security rules still apply when creating an object. For example, you cannot ACCESS_SYSTEM_SECURITY

even gain access to a newly created object, unless you have the privilege SE_SECURITY_NAME

.

It should also be emphasized that when accessing an object using an existing public handle, only the access rights to the handle are checked, not the current security permissions of the object. If you were granted a specific access right when you opened the handle, it doesn't matter if the security changes to the object have since been changed to remove that right from you.

Conversely, if a handle has not been opened with the permissions required to perform a given operation, you will not be able to perform that operation using that handle, even if the permissions on that object entitle you to do so.

This is why the parameter is dwDesiredAccess

so important; if you give up a right that a particular operation requires, that operation will fail, but if you ask for an overly broad set of rights, you might be denied access. Fortunately, in most cases the documentation is straightforward, so a little attention to detail is required.

+2


source






More articles:


All Articles