August, 2006

  • The Old New Thing

    The wisdom of seventh graders: Contributions to class discussion


    (In the continuing sporadic series on the wisdom of seventh grade students.)

    My friend the seventh grade teacher once had to deal with a class that had gotten out of hand by assigning the students a short essay in which they had to address three questions:

    • How am I contributing to class?
    • How am I detracting from class?
    • How can I contribute more while detracting less?

    One of the more disruptive students answered the questions thus:

    • How am I contributing to class?
      "I tell jokes."
    • How am I detracting from class?
      "Sometimes I talk out of turn."
    • How can I contribute more while detracting less?
      "Tell better jokes."
  • The Old New Thing

    The dialog class goes under the sneaky name WC_DIALOG


    An anonymous commenter wanted to know how to create a dialog box with CreateWindow. The window class for dialog boxes is WC_DIALOG. I'm not quite sure why anybody would want to create a dialog box this way, but there you have it.

  • The Old New Thing

    How do you wash soap?


    Steve Makofsky wondered, "How do you throw out a garbage can?". Along similar lines, I always wondered how you washed soap.

  • The Old New Thing

    If you work at a company, it's not your computer any more


    My posting a while back on solving one problem by creating a bigger problem was written from the standpoint of an IT department doing something like tweaking a logon script. I even mentioned that context partway through but clearly didn't highlight it clearly enough.

    So say you're an IT department and somebody says, "Oh, just install this other program and learn a new programming language and convert your existing batch file to it, and then your problem will be easy to solve." You might not be too excited about that type of "solution". And even if you decide, "Okay, I can justify to my boss taking a week away from my other responsibilities to convert our existing logon script (and all the helper scripts that assumed that the root logon script was written in batch, say, because they shared environment variables with it) to this new language and debug the result," you still have the problem of getting that new script interpreter onto all your company's computers so that when people log on, your new fancy logon script can run at all.

    And since you're a corporation, you have a whole new set of problems. What are the licensing terms for that new script interpreter? (A home user may just click "Next" through the license agreement without reading it; a corporation doesn't have that luxury.) How are you going to deploy this new script interpreter to all your computers? (Will it require a reboot since the installer may want to do things like modify the global PATH?) If you have a problem with the script interpreter, who provides the support? Will you have to pay extra to have it covered by your existing support contract? If somebody finds that the script interpreter is in violation of a patent, is your company liable for infringement since you are using that script interpreter as part of your regular business activities?

    Maybe these questions are easy to answer, but you still have to ask them.

    Now, let's suppose you are, say, just a regular employee at a company rather than part of the IT department. Can you just take a program that you bought or downloaded and run it on a company computer? Odds are that if your company has an IT department, it also has a policy on running "unauthorized" software on company computers. (They probably don't care how legal it is, IT departments will almost certainly get very upset if you start running a peer-to-peer file sharing program on your corporate network.)

    For the home user, the activation energy is much lower. You just have to convince one person to learn this new language and translate their batch file into it. The batch files of home users are probably not hundreds of lines long, so the translation will probably be manageable. But you may have a harder time of selling your proposal if the batch file is 800 lines long.

  • The Old New Thing

    As I recall, Germany did not ratify the United States Constitution


    I remember reading a news report on a court case wherein the defendant claimed protection under the First Amendment of the United States Constitution. An interesting angle, especially since the case was being tried in Germany under German law. I may be wrong, but it is my impression that Germany did not ratify the United States Constitution.

    There's actually a point to this anecdote. Occasionally, when someone notes that Windows doesn't do one thing or another thing for legal reasons, people will post comments saying something like, "Well, a German court ruled that XYZ is legal, so your reason is bogus." Or, "The case of P vs. Q established that XYZ does not apply, so that concern is irrelevant." Or more subtly, "It has been determined that DEF is allowed." (Whose courts? Whose constitution? Is allowed where?)

    You may not realize it, but Microsoft sells software throughout the world, and different parts of the world have different laws. What is legal in one country may not be legal in another, and Windows needs to conform to the intersection of all those laws. (On rare occasions, it will change its behavior based on what country you're in if that country's laws are significantly at odds with those of the rest of the world.) Claiming protection under the United States Constitution or citing a U.S. court decision doesn't carry much weight in front of a German judge.

  • The Old New Thing

    How did "Start Me Up" become the theme for the Windows 95 launch?


    Add this to your trivia pile. Keith Combs links to a pair of articles that that go into the history behind how Start Me Up become the theme for the Windows 95 launch. Part 1, Part 2.

  • The Old New Thing

    Try to avoid having BOOL function parameters


    Generally speaking, I believe that you should try to avoid giving functions a boolean parameter (BOOL, bool, etc.) unless the meaning of that boolean parameter is blatantly obvious. Examples of obvious meaning would be the second parameter to the EnableWindow function (TRUE obviously means the window is being enabled and FALSE means that it's being disabled) and the final parameter to ShowScrollBar (TRUE obviously means the scroll bar is being shown and FALSE means that it's being hidden). In both of these cases, the meaning of the boolean parameter is encoded in the name of the function itself.

    But for functions like CreateEvent, what does that first BOOL parameter mean? First, you have to realize that the first BOOL parameter controls whether you get an auto-reset event or a manual-reset one. Does FALSE create a manual-reset event? Or is that done by passing TRUE? I can never remember and I have to go looking it up each time. That first parameter should have been declared as, say, a DWORD or, even better, an enum with two legal values, EVENTTYPE_AUTORESET and EVENTTYPE_MANUALRESET.

    Even worse is that CreateEvent has two BOOL parameters. Like anybody reading the code later can remember which comes first.

    And the mystery bools keep coming. Consider, for example, StreamReader(Stream, bool). What does true mean? Or false? Heck if I know.

    Mind you, this is just my opinion. Others may disagree with me.

  • The Old New Thing

    We know it's insecure, but we want to do it anyway


    I remember a question from somebody who asked, paraphrasing:

    We're writing a secure screen saver that the user can interact with. We're going to present the user with various types of information, and if they click on a hot link, we want to launch a web page on their desktop once the user unlocks the workstation. We know it's insecure, but we want to do it anyway.

    Apparently these people didn't get the memo on security.

    Windows tries to make it hard for you to do this to a secure screen saver. The restrictions on secure screen savers have gotten tighter over time. Originally, secure screen savers were isolated by putting them on a separate desktop. Nowadays, Windows also runs the secure screen saver in a job object, and when the user unlocks the workstation, all processes in the job are forcibly terminated. Even if you came up with some sort of workaround for this, it's entirely possible that your workaround will be treated as a security hole and rendered ineffective in a future version of Windows.

    Suppose you find yourself some workaround and are willing to concede that your technique is living on borrowed time. It's still a bad idea. One of the aspects of security that doesn't get much attention is repudiation. Responding to the user's actions from a secure screen saver to do anything other than unlock the workstation gives the user plausible deniability. "Yes, I know it's on your auditing logs, but I assure you, I didn't click on that link. When I came back from the printer room and unlocked my workstation, this web site appeared. It must have been somebody who wandered into my office."

    If your screen saver does anything nontrivial, it becomes something the user can plausibly deny, because any random person walking by could have done it. You have an untrackable and unattributable action. Network security administrators really get the heebie-jeebies when you say "untrackable and unattributable action".

    I'm told that when people ask for this sort of "interactive secure screen saver", they typically have some sort of process control program that they want always to be available. The thing is, if you're going to trust random passers-by with your control program, then you have basically decided that your computer's physical security is already assured. In that case, you may as well create a special account, configure the computer to auto-logon with that account, and put the control program in the special account's startup group. Just run the program like normal. Don't try to pretend that wrapping it inside a "secure screen saver" accomplishes anything.

    Sidebar: While the rules for secure screen savers have gotten tighter over time, the rules for insecure screen savers have gotten more and more relaxed. Insecure screen savers are run on the user's desktop so that they can do the sorts of funny things that they got away with on Windows 95 such as taking a snapshot of the user's screen and using it as the basis for a jigsaw puzzle that it animated. Windows used to kill insecure screen savers as soon as the user touched a key or moved the mouse, but that behavior was disabled in order to allow people to write "interactive screen savers". (Remember PointCast?) Some people might argue that allowing insecure screen savers to interact with the user was a bad idea. (Yes, Internet Explorer at one point had a screen saver that did something like this. I'm told that in follow-up surveys, no customers actually admitted to liking the feature.)

  • The Old New Thing

    Moving a file does not recalculate inherited permissions


    Inherited permissions on an object are established when it is created. Once the object has been created, you can change the permissions of the parent and it won't have any effect unless you explicitly ask for the inheritable properties to be re-propagated to the child objects. (You may recall that the CREATOR_OWNER SID works in a similar way.) This rule applies to files, though that can lead to behavior that some people might consider non-intuitive.

    Files are strange from a security perspective because a single file can have multiple parent folders, thanks to hard links. Suppose you have two directories DirA and DirB. DirA has an inheritable permission that gives UserA full access and denies access to UserB, while DirB does the same with the roles of the two users reversed. It's easy to tell who the parent of a file is when it is created, since a file is created by giving a path, and you can extract the parent from the path. For example, if the file DirA\File is created, it will naturally inherit permissions from DirA.

    One the file is created, though, that's the end of it. Inheritable permissions don't have any effect any more.

    This simple rule wouldn't normally cause any problems, except that files have properties unusual among most named objects: They can go by multiple names (thanks to hard links) and can change their names (via renaming). The apparently counter-intuitive behavior stems from confusing the object with its name.

    For example, suppose we create a hard link to DirA\File under the name DirB\File. What effect does this have on the file's ACLs? Answer: None whatsoever. The inheritable ACLs on DirB aren't applied to the file since the file is not being created. Besides, you couldn't apply the inheritable ACLs from DirB even if you wanted to because it would create a paradox: The file resides in both DirA and DirB, but each of those directories contains contradictory inheritable permissions. What would the result be if you somehow managed to apply both of them?

    All right, then. We have no choice but to decide that a file's ACLs don't change when you create a hard link. Now delete the original link DirA\File, leaving just DirB\File. Does this change the ACLs now? If you believe that it should, then you're saying that inheritable ACLs can take effect even when nothing got created! After all, we didn't create a hard link; we deleted one.

    Okay, maybe you concede that deleting a hard link shouldn't affect the ACL. But what did we just do by creating a hard link and then deleting another one? The net effect is that we moved the file from DirA\File to DirB\File. Which brings us to our third example: Renaming/moving a file does not change its ACL.

    We've just rediscovered the simple rule that inheritable ACLs take effect only when a file is created. Nothing special happens when a new hard link is created or when the file is moved.

    Of course, that simple rule holds only when you look at the file system at a low level. Layers built on top of the low-level file system can end up complicating our simple rule.

    When you move a file across volumes with the MOVEFILE_COPY_ALLOWED flag, you're saying that "move the file if possible; if not, then convert it to a copy/delete operation". The copy operation creates a new file, which means that inheritable properties on the destination folder do take effect. But only if the file motion crosses volumes. If you're moving the file within the same volume, then the ACL remains unchanged. How confusing. When you pass the MOVEFILE_COPY_ALLOWED flag, you lose control of the ACL. (You actually lose control of much more than just the ACL. Since the file is being copied, none of the attributes from the original file are kept on the copy. The copy inherits its encryption and compression status from the new parent directory. The copy also gets a new owner, which has follow-on consequences for things like disk quota.)

    Another layer built on top of the low-level file system operations is the shell's copy engine. If you use SHFileOperation to move a file and pass the FOF_NOCOPYSECURITYATTRIBUTES flag, then it will not preserve the original ACLs on the moved files but will rather recalculate them from the destination's inheritable properties. (If you want to do the same thing in your own code, you can call the SetNamedSecurityInfo function, specifying that you want an empty, unprotected DACL.) In Windows XP, the shell decides whether or not to use this "naive mode" ACL management based on the following algorithm:

    • If the MoveSecurityAttributes policy is set, then the policy determines how ACLs are handled when files are moved. (ACLs are reset if set to "0" and are preserved if set to "1".)
    • Otherwise, the "Use simple file sharing" setting controls how ACLs are handled when files are moved. (ACLs are reset if simple file sharing is enabled and are preserved if simple file sharing is disabled.)
  • The Old New Thing

    Those folks from Birmingham talk funny, and I mean that in a scientific way


    In celebration of their tenth birthday, the Paramount Comedy Channel in the UK commissioned a study on how regional accents affect perceived funniness, and the conclusion was that people from Birmingham have the funniest accents. The Received Pronunciation, which is the only British accent most people in the United States are familiar with, came in dead last. I'm sure that there are some nuances of class that I miss out on when I watch a British-made film due to my lack of familiarity with the connotations that each accent brings to the table: Which accents are the aristocratic accents, the working-class accents, the stereotypical football fan accents, and so on.

    I wouldn't be surprised if the advent of mass media has taken its toll on regional accents, softening the harsher edges and bringing them a little closer together. Which I think is kind of sad.

    Personally, I think the northern accents are funnier, like the ones used by Wallace and Babs.

    [Assorted typos fixed, 10:15am.]

Page 1 of 4 (39 items) 1234