|
You don't even do them when we do remind you! 
|
|
|
|
|
Who are you ? 
"We can't stop here - this is bat country" - Hunter S Thompson - RIP
|
|
|
|
|
You're asking the wrong person... I'm still trying to work that one out myself!
|
|
|
|
|
Yes, it is a good clue 
|
|
|
|
|
Microsoft in their infinite wisdom, have so locked down windows services, that you cannot interface with them using standard IPC mechanisms like Memory Mapped Files or Named Pipes.
The upshot of this is it's not possible (I think) to do IPC with a running service without messing with some user account settings or service account settings that should not be messed with.
Frankly, I don't want windows auth on a direct IPC channel that I control, I map, and I set up.
It's ridiculous. An administrative nightmare. Why did they do this? Why? It doesn't help security at the end of the day, because to use it you *must* mess with account settings in a way that makes your system *less secure!*
Why can't I have an IPC mechanism that simply doesn't care about windows credentials? I don't want to use TCP/IP for this, which seems my only other option, but it's not even reliable because I can't guarantee a fixed TCP port to use for the client/server. How do I know it's not in use? If i pick one at random, how can i negotiate it with the client? It's again, ridiculous.
They've painted me into a heck of a corner. I don't know why it is this way. Were people not thinking?
Am *I* missing something? What gives?
Real programmers use butterflies
modified 5-Aug-20 0:42am.
|
|
|
|
|
really ? It's been a while, but I didn't think there were major issues with IPC and services .. in the environment I was running we always had a dedicated service user to which one could (and was expected to) assign access/privileges etc
I did a quick search and found this Asynchronous Named Pipe IPC and Messaging - look at "Quote: 1. Named Pipe Access/Security:
The intended use of my library was IPC between windows forms application and windows service. Knowing that windows services run in different session, it was obvious that a pipe created in a service may not be accessible by a desktop application. At first, I thought that I must enable windows service to interact with the Desktop (it’s a check box that must be checked manually in service configuration console). I did not like such solution because it requires manual user interaction/configuration after the installation. However, further investigation revealed that windows pipes provide access rights option via .Net code. I enabled access to “Everyone” and pipe server was visible to regular windows forms application. Access modification is not necessary if the client and the server are running under same privileges in the same session (for example two windows forms application executed by the same user on the same machine).
|
|
|
|
|
Garth J Lancaster wrote: I enabled access to “Everyone” and pipe server was visible to regular windows forms application.
Ummm, this seems problematic. I wonder what they're setting to Everyone. I'll look at the link. Maybe it has my answer. Thanks
Real programmers use butterflies
|
|
|
|
|
IIRC, you can use COM to communicate between a Service and a user application.
For the most part, you don't care about the transport. All you care about is the API, which is what COM provides.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
COM - 'ugh' - was never one of my favourites when I was a c++ programmer - In C# I'd rather use ZeroMQ or such if it came to such a choice and I couldn't use pipes/shared memory
this isn't an attack on you Daniel, if you're a COM guru good on you 
|
|
|
|
|
Yeah. I suppose I could, but I don't like the idea of DCOM for IPC for some reason
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: I don't want to use TCP/IP for this, which seems my only other option, but it's not even reliable because I can't guarantee a fixed TCP port to use for the client/server. How do I know it's not in use? If i pick one at random, how can i negotiate it with the client? It's again, ridiculous.
Not to forget that even when you could do all that, then come a new "I know all better" moron in the IT department, they change the firewalls and puff... you are fvcked up.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
That's what production documentation, change control, etc etc are supposed to prevent (sorry, I had the benefit of working for a 'large shop')
|
|
|
|
|
Garth J Lancaster wrote: That's what production documentation, change control, etc etc are supposed to prevent when done properly, being updated regulary and informing all relevant parts soon enough to prepare for it
FTFY
Garth J Lancaster wrote: (sorry, I had the benefit of working for a 'large shop')
And I have worked for a large shop too, where the IT just changed the IP of the production and statistic servers (3 pieces) without telling any of the production plants abroad. The action ended in 7 weeks without mirroring of the production buffered data (at least individual requests continued working), no mirror of the software libraries and no backup of our statistic DB. 7 weeks where 2 weeks where looking for the problem, we had all our requests done by DNS-Name but the firewalls were "reconfigured" to use the new IP. 1 Week more to get all needed signatures for the respective change_requests (in this part of the process of course they were active again), and 4 weeks to wait until the damned firewall entries were corrected and activated.
To answer your comment again I can only say:
Theory and Practice are in theory the same, but in practice...
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Quote: where the IT just changed the IP of the production and statistic servers
Ha ha, said the clown!
|
|
|
|
|
What is so funny?
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I wrote a tray app that communicates with a Windows service using named pipes, and it worked fine. Are you talking about .Net Core maybe?
|
|
|
|
|
I don't know "honey the codewitch's" situation, but your experience matches my recollection
|
|
|
|
|
Nah, it's DNF 4.72 
Real programmers use butterflies
|
|
|
|
|
In my several decades of working in the Win32 environment and now Win64, I have never, ever had an issue with credentials and inter-process communication. Not a single time and I have worked with pipes, events, mutexes, and shared memory extensively.
What I mean by this is, in and of themselves, none of those IPC mechanisms require anything involving credentials. Any issues you may have with them are arising from a different level such as dealing with a service OR they are being imposed by something in .nyet.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
It might be a .NET issue, but it looked like I was getting a win32 error result since it was 5: access denied
Real programmers use butterflies
|
|
|
|
|
"I would be looking for better tekkies, too. Yours are broken." -- Paul Pedant
Context: The inability to create or consume CSV files. 
|
|
|
|
|
|
"Anti-escape baffle", yeah, so when that 7,000 volts doesn't do the job. 
|
|
|
|
|
They finally built a better one.
Yuya Tuya want your mouse? I've got one.
Yuya Tuya want your mouse? I'm sayin'
modified 4-Aug-20 22:32pm.
|
|
|
|
|
I need a bowl and a half of walnut to catch a mouse - and it does not kill it...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
