Why Effective Permissions Sometimes Aren't Correct

You may have noticed that Windows's "Effective Permissions" utility (somewhere in the Security tab on files) doesn't always report what permissions you have correctly, especially if you have local admin and not domain admin. This is due to a subtlety of SIDs.

A Security IDentifier (SID), uniquely (ding ding ding! there's the key) identifies a security principal - a user, group, or special claims-based thing like TrustedInstaller. Users on a domain each have a SID and that is unique across all computers. The Administrators group (for which most files have an ACL entry), however, is not specific to a domain or computer. Its SID is always S-1-5-32-544, whether it's the Administrators group on the domain (not the Domain Admins group), the Administrators group on the file server, or an Administrators group on some random client computer.

Suppose you're a local admin on your machine and therefore a member of S-1-5-32-544 on your computer. When you hand your impersonation token over to a file server and say "hey, I'm an admin, gimme this file!", it says "alright, let me check that", consults its impression of S-1-5-32-544 (because it has a group with that SID, of course), says "hey, you're not on that list!", and denies you access.

Your computer, on the other hand, sees the ACL entry for S-1-5-32-544, says "oh cool, you're a part of that, you can have all the access." The Effective Permissions utility does not ask the remote host; it only checks the SIDs on the ACL.

There might be other ACLs you can't see, like the ones in the mini-ACL editor you get when running the Advanced Sharing wizard. Those aren't on the file system like normal ACLs; they're extra restrictions processed by the LanMan service. You might also be subjected to restrictions for situation-based principals like Network (S-1-5-2), the faux-group of people who are remotely accessing the file.

Robotics - Moving Around

As I'm pretty used to by now, very few people came to today's robotics meeting! We did at least have an engineer, who was tinkering with a generic frame and trying to make do with our lack of relevant parts. (We have no axle hubs, not enough motors, not the right kind of wheels, a broken Samantha module, the wrong type of battery connector, and a poorly-functioning wire stripper.) While he worked with that, I oversaw the continued assembly of the field.

We got the kickstands and ball holding chambers set up yesterday. Today, we riveted the small wooden parts involved in the mount of the high center ball tube. We would have attached the tube and the guard/wrapper/thing around it, but for some reason the instructions call for that to be done with a stapler and we couldn't find one.

More interestingly, I continued work on the other team's tele-op program. I ran a test with buttons and tones to determine whether anything involved in the joystick was being sent to the robot - it was. I tried controlling motors with buttons - it worked, but there was insufficient traction on the wheels to move with only one wheel at once. After they fixed that, I tried controlling the motors again with the thumbsticks - it produced the same strange going-in-circles effect.

After a little bit of research (looking around in the example programs), I discovered that I not only have to call getJoystickSettings(joystick), but I have to use the "joy1_y1" and company members of default "joystick" variable. I had tried both of those things individually, but apparently never together. For some reason, the joy1Btn function works even if I don't call getJoystickSettings. Anyway, I hooked the thumbsticks up to the motors again and they were able to drive.

People were very excited, so I gave everybody in attendance a few minutes to drive the robot around. One managed to accidentally trip the kickstand, releasing a flood of balls, which was pretty exciting. Once everybody had their turn, I started implementing a virtual gearing system for precise controls. Unfortunately, their NXT ran out of battery power, so testing that will have to wait until next time.

Fix for RobotC 3.x Not Allowing WiFi Connections

I discovered a curious bug in the RobotC development environment today, at least in version 3.62. Sometimes, especially when the user running the IDE is not an administrator, WiFi connections to the robot will not work at all. What happens is that the robot search dropdown loses the WiFi options and the box for robots found via WiFi says something to the effect of "Searching for robots via WiFi is disabled."

I found one forum post that recommended checking the "Enable Wireless Searching for NXT" under Preferences under View. I tried that, but it did not do anything to solve the problem, even after a restart. It took me quite a while to figure out a real solution.

What you need to do is find an account where RobotC does do WiFi right and export the RobotC registry tree. This is found at HKCU\Software\Robot Academy. Open the Registry Editor by opening the Run dialog and launching "regedit". Expand the "HKEY_CURRENT_USER" folder, then Software, then just select "Robot Academy". Under File, use Export to save the selected tree to disk. If you have no environment in which RobotC behaves as expected, download my version of the registry tree.

Once you have acquired a working registry configuration, log into the user account for which it is not working and merge (import) the exported .reg file into your user registry (just double-click and OK any warnings). Launch RobotC and everything should be good.

Robotics - A Riveting Tale

Once again, very few people actually came to the robotics meeting. We still don't have a robot or materials necessary to make one do interesting things, so we just continued building the field. At a meeting which I could not attend last week, they found a drill and removed the incorrect rivets from the center field assembly pipes.

We installed the correct pipes today and started attaching the other Plexiglas side of the center assembly. The first rivet we put in, it didn't actually go through into the side of the structure - only into the Plexiglas - so we had to drill it out of the Plexiglas while being careful to not shatter it. Once we got longer rivets, the attachment went well.

I did a little bit more work on the RobotC program for the other team (which at least has a robot), but it still exhibits the strange problem of not getting the joystick movements.

Crushers - Polish That

I have been pretty stressed lately, and playing my old arcade-style game Crushers has been a really awesome way to relax. I consider it my best production, but it is currently in a state of half-brokenness because I ran out of time a few months ago while I was doing lots of updating/refactoring. With crosscountry done and another unit of communication class almost over, I want to use a little of my free time for a few days to polish Crushers.

Currently, it has a bug in which blocks are sometimes spawned not aligned to the usual 16x16 grid, which causes weird glitches, teleporting, and disappearance when they collide with another block. I have a pretty good idea of how to fix it, but it will take a little bit of time to go through the block spawning code (which needs a good refactor anyway).

Additionally, since I and pretty much everybody else have widescreen monitors (16:9 aspect ratio), there are blank black bars to the left and right of the Crushers game area. Adjusting the view properties to use a widescreen size will be trivial.

Some adjustments need to be made to the suffocation mechanic, like having the air particles track the player when he is in a 1-wide hole. It could also benefit from a dynamic grid of oxygen sources , but that's a pretty advanced programming thing.

The antigrav dimension could use some work, like being rebalanced to not be a guaranteed death trap. It could also be incentivized, maybe with some score bonuses for being in it or diminishing returns in the normal dimension.

I have other grand ideas, but for now I want to get bugs fixed and get the full v2.5 out.

Forgotten Windows Feature: Document Scraps

Up to Windows XP, there was an obscure little feature of the shell called "scraps." It is a system which, essentially, allows you to take an OLE object that supports dragging-and-dropping (and serialization) and place it in the file system as a file. These files, scraps, are even given special treatment kind of like shortcuts - extensions never seem to be shown for them (though they do have extension SHS).

They are usually generated from Microsoft Office products, by dragging selected text or objects out of the Office window and onto the desktop. They can then be dragged in later to a different document, or double-clicked like normal files to launch the owning application and paste the contents into the new window.

You can read the Microsoft KB article for the official information.

Robotics - Design Day

Today's robotics meeting did not involve a lot of robotics. Instead, we were in the upper school computer lab to work on the engineering notebook and T-shirt designs. I made a little more progress on the notebook; it is going slowly, though. The other designers dug up last year's shirt design and adapted it to have our names on it. This is good - I liked the old design.

We really need to get back to robot building.