sockets are securable objects???
Corinna Vinschen
I have an effect in a service which I really didn't expect.
Roughly spoken, the application is doing the following:
- Start under SYSTEM account
- Open a socket, wait for connection
- On connection, user authentication
- LogonUser()
- ImpersonateLoggedOnUser()
At that point the user can choose to do several actions. One of
these actions results in duplicating the socket for another task.
Duplicating the socket is done by using the WSADuplicateSocket()/
WSASocket() call chain with dwProcessId == GetCurrentProcessId().
The strange effect here is that the WSADuplicateSocket() fails
with WSAEINVAL if the authenticated user is a non-privileged user,
say, s/he's just in the local group "Users" with no extra user
rights. OTOH it works nicely for members of the admins group.
I can workaround that by calling RevertToSelf() before the call
to WSADuplicateSocket() and by calling ImpersonateLoggedOnUser()
afterwards.
However, I don't understand that behaviour since sockets are not
documented in MSDN as so-called "securable objects". The reference
to, e.g., SetSecurityInfo() does not enumerate sockets in the
"Remarks" section as an object type supported by SetSecurityInfo().
Does anybody have an idea what's going on? I assume it has something
to do with the fact that one parameter in the WSADuplicateSocket()
is the process ID for which the socket should be duplicated and that
the impersonated user doesn't have the permissions to open the process
to get or set the needed information. Is that correct or do I just
miss something? I would really like to avoid the RevertToSelf()
stuff but I don't know how, currently.
Thanks for any hint,
Corinna