The case of the volume label that doesn’t change


A customer liaison forwarded a problem from their customer: When the customer changed the volume label on a drive, the change is not reflected in Explorer. Explorer continues to show the old volume label.

A ProcMon trace revealed that svchost.exe running as NT AUTHORITY\SYSTEM attempted to open the root of the drive but got STATUS_ACCESS_DENIED. The access was coming from the shell hardware service at a point where it calls Get­Volume­Information to get the volume label.

Okay, that makes sense that the shell hardware service was trying to access the volume to read the volume label. After all, it was told that there was a change to the volume label, so it's going to the volume to see what the new label is. The question is why the shell hardware service, running as SYSTEM, got STATUS_ACCESS_DENIED.

I asked, "How did that happen? The SYSTEM account should have full access to the drive by default. Did the customer apply a custom CL that revokes SYSTEM access? You'll find that a lot of things stop working when you revoke SYSTEM access."

The customer liaison wrote back, "Indeed, the customer did remove the SYSTEM account from the drive's permissions. I am not sure exactly what they were thinking when they revoked SYSTEM access. I need to ask them."

We didn't hear back from the customer, so maybe the customer was too embarrassed to explain why they revoked SYSTEM access to the drive.

Another case of a customer changing a security setting without really understanding why they did it, and then wondering why stuff stops working.

Comments (10)
  1. skSdnW says:

    I thought System was normally a member of the Administrator group so did they remove that group as well or specifically deny the System user?

    1. Joshua says:

      Nope, System is not in Administrators group. If I recall correctly, adding it to administrators group on NT4 allowed it to log in on the console. I recall there was some reason why this wasn’t a particularly good idea.

      1. skSdnW says:

        Process Explorer tells me that the relevant svchost instance is a Administrators group member (Win8.1).

        1. Joshua says:

          I checked. It looks like services that start as System don’t get tokes from LogonUser, so that accounts for the discrepancy.

  2. Karellen says:

    If the shell hardware service can’t access the volume to read the volume label, how did the customer change the volume label? If writing the volume label doesn’t go through the hardware service, why does reading the volume label do so?

    And how did Explorer get the old volume label of the drive to show, from before the customer changed it?

    1. skSdnW says:

      Explorer uses PIDLs/IShellItem and they often contain cached information (size, 8.3 name etc.) so the MyComputer IShellFolder shell namespace implementation in shell32 sits between Explorer and the filesystem/volume manager and owns the PIDL format for that folder.

    2. Even though SYSTEM doesn’t have access, the user does. So the user probably used the LABEL command to change the label. And Explorer runs as the user, so it probably used GetVolumeInformation to read the label. But since the service cannot read the label, it cannot notify Explorer, “Hey, the label changed.”

      1. smf says:

        does that mean there is a service polling for volume label changes all the time, just so that it can notify explorer?

        1. It’s not polling. It’s subscribing to volume change notifications.

  3. Harry Johnston says:

    My guess: the intent was to add an ACE to the existing ACL but they messed up the code and wound up deleting all the existing entries. Easy to do, particularly if you’re using the older APIs.

Comments are closed.

Skip to main content