Skip to main content

Mi Vista es su Vista

Today I attended a code clinic about programming Windows Vista. I like attending the Microsoft learning events because they are free and the cross-section of talents are comfortable. There are some real old-timers that do Windows platform programming. They're fun people.

Anyway, one thing that I took from that talk was about how Vista handles registry access. In the past, if your application did not have permission to make registry changes, it would get an error. Now, Vista creates an isolated, virtual, registry for your application. This gives your application the impression of it working properly, and for the most part, it's correct. In my case, though, it's not.

I program middleware Windows Services that make use of .NET Remoting. To manage the services, I create a manager application that is available from the task tray. You've seen something like this with SQL Server Manager, if you do SQL Server programming.

So I figured out how to make my service run with elevated privileges, so now it runs with full-control as Local System. That was a great triumph. Alas, though, the service manager runs as the local user account. This has some unfortunate side effects.

From my service manager, I have a UI to make runtime configuration changes to the service it controls. The manager does this by writing to the registry. Because it is using LUA (local user access), it can't write to the real registry, so Vista lets it write to the "virtual" registry. So there I am thinking that I am fixing my configuration problem with the service, but darn if it just doesn't seem to work when I restart the service. That's because my service is reading its config from the real registry while my service manager reads it from the virtual registry.

The next time you develop a service manager that controls a service, remember to isolate all configuration changes in the service and not the service manager. The manager should just request changes in the process space of the service and not the manager.

I am yet to figure out how to make my service manager run as the administrator. I think it needs to be signed with my PFX file. Hopefully that solves the problem...

Popular posts from this blog

How To Cancel ATT Uverse

I was a subscriber to the AT&T Uverse service for a little over 2 years. In that time, we had experienced good service for the first year, and then it sucked. After 12 months, or there in, the service degraded quickly, and would stop working all together at times. At first it would die for a short period of time, usually when we were not home. Then it would get progressively worst, until there was an entire week of no service. We had technicians at the house trying to fix the service, but it would repeat the behavior quite consistently.

On January 15th we finally gave up and switched to a lesser service, COX TV and Internet. In the past we had cable service and it was always reliable, but not as good as the AT&T digital service. COX doesn't have nearly as many HD channels, but that's not enough. We needed internet to be reliable, and AT&T couldn't deliver that.

Cancelling the AT&T service was a nightmare. Try to find anything about such things on their web si…

Splunk To root or Not To root

Today I added some add-ons to my splunk and did some sysadmin on the server. Restarted and noted the splunkd was not running. Ahh, well, that's typical. Starting the splunk daemon is easy enough:

Start Splunk - from the people who made splunk.

There are two ways to start splunk, as you can read from above. One is to run the "splunk" process from your root shell after logging in. This will run splunk as root. The other is to use the nifty systemctl service script to daemonize the process.

Prior to today, I had the same problem and ran the splunk process as root. This was foolish. If you happen to have once started splunk as root, and then successfully started splunk as the "splunk" user, you will find that your splunk login page is empty. You get the background picture, but no input controls.

Damn. Google that, nada. Damn again.

Today, I learned alot more about selinux and permissions and labels, so I investigated the "web_service" log (/opt/splunk/var/…

Whiskey Tango Foxtrot

Today is one of those Whiskey Tango Foxtrot kind of days. I've been tracking a real November Sierra since December, and even reported it. I figured it was a bug, so I submitted it to the security folks. Their response? "We're not the team for this problem." ok.

Now today I see two data points, one weird-o one-timer kind of probe. Yup, for real, a solo IP in the gigabytes of logs that my splunk eats. Yet this IP correlates with another IP that has been on my radar.

So I get out my splunk and pull a "deny" query on this IP. Not only does it generate IPS hits from my desktop, outbound to destination, but I see inbound activity from this IP (also denied, of course).

(2017-03-29T17:56:44) firewall:msg_id="3000-0150" Deny1-Trusted0-External9840tcp2064 [desktop_ip]