Able to access System32

I wrote a test which relied on not being able to access System32. I know, maybe stupid, but it works on regular machines. Should the CI environment replicate this behaviour? ie. Should Travis block access to System32 by default? As is the default Windows configuration

Here is the build in question: https://travis-ci.org/sindresorhus/cpy/builds/546992254

C:\Windows\System32 ? It holds many exe’s (C:\windows\system32\find.exe) and other things vital to using the OS, and thus also testing the OS.
Ideally CI shouldnt block anything at the OS level; any blocks should be in the VM monitor / hypervisor.

The user “travis” is probably in the Administrators groups, or similar, so that early adopters dont need to fight Windows “security” to get easy stuff done.

I guess you could create a new user without admin rights, and ‘run as’ your tests as that user - then it should be like the default Windows configuration for normal users.

@tom-sherman, if you wish to check how your code handles EPERM, create your own file system object and set its permissions accordingly.


To check whether you are running with elevation, use $WINDIR/System32/whoami.exe /groups. If not, the BUILTIN\Administrators will be present in the output with flags “Group used for deny only”; if yes, it will be marked as “Enabled group”.


If the build console runs elevated, I believe that’s because Windows has no equivalent to sudo – so if it wasn’t, the user would have no way to install software.