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
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.