# Solved: C++ Windows 7 socket problem



## Nickolodeon (Apr 14, 2010)

Hi, guys.
I'm trying to use socket(...) function in Windows 7 and get WSAEACCES=Permission denied
error right away. Although I develop in VS and logged in into Win7 under my (admin) account, programmatic call to function (the name of it I can't recall, code is not on this machine) that returns whether user is an admin yields FALSE, that is I am not admin which is weird. I think it is the reason why socket fails. 
Any suggestions?
Also I am looking for a way to communicate through sockets without priv_level system interference, b/c/ I need it to run under any user account.


----------



## tomdkat (May 6, 2006)

What kind of socket are you trying to create?

On this page, it states this about your error:


> Permission denied.
> 
> An attempt was made to access a socket in a way forbidden by its access permissions. An example is using a broadcast address for sendto without broadcast permission being set using setsockopt(SO_BROADCAST).
> 
> Another possible reason for the WSAEACCES error is that when the bind function is called (on Windows NT 4.0 with SP4 and later), another application, service, or kernel mode driver is bound to the same address with exclusive access. Such exclusive access is a new feature of Windows NT 4.0 with SP4 and later, and is implemented by using the SO_EXCLUSIVEADDRUSE option.


I'm helping to port a network-aware Windows app to Windows 7 so your issue is of interest to me. 

Peace...


----------



## Nickolodeon (Apr 14, 2010)

People say, you should setup linker options to bypass UAC, and NOT enable UAC (2 options). 
Also starting VS by "Run as administrator" menu helps. I'm going to experiment with linker options though, because I need any user to run the app, not just admin.


----------



## tomdkat (May 6, 2006)

That doesn't sound like a "well behaved" approach but if it works for you, more power to you. 

Good luck!

Peace...


----------



## Nickolodeon (Apr 14, 2010)

Well, requiring to run the app as an admin isn't exactly a neat way to overcome the problem, I agree.
But tweaking the linker configs is. In fact it is a prefered way to do it. I haven't laid my hands on it yet, though) and hope tha theory will be in accordance with practice


----------



## tomdkat (May 6, 2006)

Think about it. Your web browser opens all kinds of socket connections but it doesn't require any special privileges to run and for the browser to circumvent the UAC would be a HUGE security hole, given how the browser can serve as the ideal entry point for malware.

Also, if you installed an older browser (think pre-Windows 7) it would probably still be able to access web sites, which means it would still be able to open socket connections.

You never answered my question above. Are you creating some kind of special or "raw" socket?

I'm not telling you NOT to use the linker flags you found mentioned elsewhere. I'm just saying that doesn't sound like a "well-behaved" solution to the problem you're having.

If Windows 7 is preventing you from creating the type of socket you need in the manner you're currently doing it, there must be a reason for it (whether that reason is good or bad). Circumventing the security system doesn't sound like a good approach but that's without knowing anything about the kind of socket you're looking to create.

In the app I'm helping to port, we're not looking to create "raw" sockets or anything of that nature. So, we probably won't run into the issue you're having. The MSDN doc on the "socket()" system call (or is it a library call on Windows?) states:


> Note On Windows NT, raw socket support requires administrative privileges.


Peace...


----------



## Nickolodeon (Apr 14, 2010)

Thanks for that quote from MSDN.
Yes, I do use raw sockets. I need to scan some ports to determine if they are not in use, so my app can use them. Raw socket connections worked fine. The thing is that I also port the app from XP to win7 and have not experienced any problems on xp. I need it to work on win7 as well (and it seems I'm getting there))
I'm sure the reason exists for implementing such a restriction in Win7. However I don't see more "legal" solutions yet.


----------



## tomdkat (May 6, 2006)

I'm not running my W7 box right now but does running the "ping" command invoke the UAC?

I also found this on the MSDN site:


> Note To use a socket of type SOCK_RAW requires administrative privileges. Users running Winsock applications that use raw sockets must be a member of the Administrators group on the local computer, otherwise raw socket calls will fail with an error code of WSAEACCES. On Windows Vista and later, access for raw sockets is enforced at socket creation. In earlier versions of Windows, access for raw sockets is enforced during other socket operations.


I know some apps, like Malwarebytes, which require elevated privileges invoke the UAC when you run them. I guess you want your app to run without invoking the UAC, if the UAC is enabled on that system, right? Invoking the UAC from a standard user account still allows that user to run the app, it's just they have to permit the app to run.

Have you tried the linker options to not enable UAC support in your app and does it work for you? Can you install Wireshark and see if it invokes the UAC on your W7 system when it runs?

I know, I know, I'm getting away from the point of the thread. 

Peace...


----------



## Nickolodeon (Apr 14, 2010)

I have tried setting up linker options and am glad to see it's working. 
The idea here is to let users who used the app and upgraded their OS to win7 continue working without meddling around with some UAC. 
What are you using sockets for?


----------



## tomdkat (May 6, 2006)

We're porting a Windows client of a niche commercial app to Visual Studio 2008 on Windows 7. The Windows client uses a proprietary communications protocol that uses TCP/IP as its transport. So, we use TCP sockets for communication with our server components running on various platforms. 

Good luck with your app!

Peace...


----------

