Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Path::homeDirectory(): asserts when run by Windows users without home directory #132

Open
Squareys opened this issue May 13, 2022 · 3 comments · May be fixed by #141
Open

Path::homeDirectory(): asserts when run by Windows users without home directory #132

Squareys opened this issue May 13, 2022 · 3 comments · May be fixed by #141
Milestone

Comments

@Squareys
Copy link
Contributor

Hi @mosra,

summarizing gitter messages: It is possible to run applications on windows through system users without home directories. In this case CSIDL_PERSONAL does not known and SHGetFolderPathW() will not return S_OK, but rather E_INVALIDARG .

This means the assert that is assumed to never possibly fail can indeed fail:

/* There doesn't seem to be any possibility how this could fail, so just
assert */
CORRADE_INTERNAL_ASSERT(SHGetFolderPathW(nullptr, CSIDL_PERSONAL, nullptr, 0, h) == S_OK);

Expectation would be that this returns a null optional instead.

Best,
Jonathan

@mosra mosra added this to the 2022.0a milestone May 14, 2022
@mosra
Copy link
Owner

mosra commented May 14, 2022

Interesting, apparently I overlooked this error case.

I have a fix locally, but would like to have an explicit test for it -- do you still have access to the home-less VM runner to explore a bit? In particular I'd like to know what environment variables are present there, especially %HOMEPATH% and %USERPROFILE%, or whether they're set to empty, to independently detect such case in a test. Thank you!

@Squareys
Copy link
Contributor Author

I seem to be unable to find documentation on what environment is present for local system/service accounts on Windows, hence I tried running a powershell script as a local service account to grep the environment. (Using this for the system account execution and this for retrieving the environment. The script is attached for reference.

That returned nothing at all, so I am suspecting that system/service accounts don't have access to the environment at all. This post hints and individual variables needing explicit access to environment variables, controlled by Windows registry values.

Powershell script for grepping the environment as system user
$ErrorActionPreference = 'Stop'

Clear-Host

$taskName = "it3xl_dummy_PowerShell_job"
# Unregister-ScheduledJob it3xl_dummy_PowerShell_job -Confirm:$false

$task = Get-ScheduledJob -Name $taskName  -ErrorAction SilentlyContinue
if ($task -ne $null)
{
    Unregister-ScheduledJob $task  -Confirm:$false
    Write-Host "Old $taskName job has been unregistered"; Write-Host;
}


$trigger = New-JobTrigger -AtStartup;

$options = New-ScheduledJobOption -StartIfOnBattery  -RunElevated;

Write-Host "Registering new $taskName job";
Register-ScheduledJob -Name $taskName  -Trigger $trigger  -ScheduledJobOption $options `
    -ScriptBlock {
    $somthing = Get-ChildItem env:
    Write-Host $something
}


#$accountId = "NT AUTHORITY\SYSTEM";
$accountId = "NT AUTHORITY\LOCAL SERVICE";
$principal = New-ScheduledTaskPrincipal -UserID $accountId `
    -LogonType ServiceAccount  -RunLevel Highest;

$psSobsSchedulerPath = "\Microsoft\Windows\PowerShell\ScheduledJobs";
$someResult = Set-ScheduledTask -TaskPath $psSobsSchedulerPath `
    -TaskName $taskName  -Principal $principal


Write-Host;
Write-Host "Let's show proofs that our PowerShell job will be running under the LocalSytem account"
$task = Get-ScheduledTask -TaskName $taskName
$task.Principal

Write-Host "Let's start $taskName"
Start-Job -DefinitionName $taskName | Format-Table

Write-Host "Let's proof that our PowerShell job was ran"
Start-Sleep -Seconds 3
Receive-Job -Name $taskName

@mosra
Copy link
Owner

mosra commented May 27, 2022

Awesome, so for testing it might be enough to just check that %APPDATA% or %HOMEPATH% doesn't exist. I made an attempt on a fix and a test in 94f841e (on the next directory-home-graceful-fail branch, #141), could you try to run UtilityPathTest under the system account? The test should fail because I don't know what error message to accept, if you could then paste the whole output here that'd be great.

Thanks in advance! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging a pull request may close this issue.

2 participants