2

I have some performance counters that write to CSV files in the default location (%SYSTEMDRIVE%\Perflogs). The directories that it creates are "special." When I attempt to browse into them, explorer complains

enter image description here

I can click "Continue" and then I no longer have problems browsing into the directories with explorer.

However, if I attempt to access the directories via an unelevated cmd shell, I get ACCESS_DENIED. With an elevated cmd, I can access the data files without a problem.

icacls reports this about the directory (before I browse into it)

MEMTEST2_20190724-000004 NT AUTHORITY\SYSTEM:(OI)(CI)(F)
                         BUILTIN\Administrators:(OI)(CI)(F)
                         BUILTIN\Performance Log Users:(OI)(R)

The user I'm running as is already in Performance Log Users.

  1. What is actually happening when I "permanently get access to this folder?"
  2. How is this directory actually secured against non-elevated access?
  3. Is there a good way to "unprotect" the directory without reconfiguring the performance counter to write to a different location?
    • I read this answer, which describes how to create an event listener to unprotect the directory when the counter starts. Is there no other way?
mojo
  • 217
  • 1
  • 4
  • 12

1 Answers1

2

This behavior is caused by User Account Control: the processes you run (including Windows Explorers and CMD) don't actually have administrative rights even if you belong to the Administrators group, you have to explicitly request them using the "Run as Administrator" command; however, this can't be done for Explorer itself, because it's always running, thus you can't run another, eleveted instance of it (unless you kill it first, thus losing your shell; this can be done, but it requires clumsy workarounds).

However, Windows Explorer itself is aware of how UAC works; so, when you try to access a folder only Administrators have access to and it detects that you are a member of Administrators but it's not running in elevated mode, it tries to be helpful and asks if you want to "permanently get access" to the folder; if you click Continue an explicit grant ACE for your user account is added to the folder: this allows you to directly access the folder instead of relying on your administrative rights, thus bypassing UAC.

What I find puzzling is, this is standard (however debatable) behavior for UAC and Explorer, but it only happens when administrative rights are involved; if you have access to a folder because you belong to a normal (non-Administrators) group which can access it, UAC should not get involved at all.

Unless Windows treats the "Performance Log Users" group just like the "Administrators" groups as far as UAC is concerned, thus requiring elevation in order to actually use its membership; if this is the case, it's news to me and I can't find it referenced anywhere.

Massimo
  • 68,714
  • 56
  • 196
  • 319
  • The permissions shown in the question for Performance Log Users only allow Read, not Read & Execute. That will prevent Explorer from opening the directory. – Harry Johnston Jul 25 '19 at 01:30
  • My user is in both administrators and performance log users. This is more than a normal permissions thing. UAC is about process elevation. How does one protect a file or directory against non-elevation? – mojo Jul 25 '19 at 02:27
  • @mojo You don't "protect a file or directory against non-elevation": this is automatically done by Windows (via UAC) for files and directories that are only accessible to Administrators; you need elevation to actually access them, even if you *are* an admin. – Massimo Jul 25 '19 at 09:29
  • Can you give me another example of a directory that behaves this way? The Windows directory doesn't require elevation to read or write. Neither does Program Files. Those are protected by filesystem ACLs. What's different about Perflogs? – mojo Jul 25 '19 at 11:50
  • I rescind my previous comment. Both directories I mentioned behave differently in elevated vs non-elevated processes. – mojo Jul 25 '19 at 15:50
  • [USER Account Control… but I’m an ADMIN!](https://blogs.technet.microsoft.com/mrsnrub/2010/08/06/user-account-control-but-im-an-admin/) (blogs.msdn.com) The behavior seems to be "documented" without useful details here. – mojo Jul 25 '19 at 16:35