Проблемы наследования Windows ACL для FTP-сервера и автоматизированных инструментов

Я настроил сервер Cerberus FTP. По умолчанию служба FTP Cerberus работает в системном аккаунте. Также у меня есть некоторые консольные приложения, которые запускаются как запланированные задачи. Они работают под выделенной учетной записью пользователя "Утилиты", которая имеет разрешения "Вход в систему как пакетное задание". Эти консольные приложения принимают загруженные файлы FTP, обрабатывают их и затем перемещают в какую-либо специальную папку архива.

Проблема заключается в том, что мои консольные приложения выдают исключения безопасности при попытке доступа к загруженным файлам. Я попытался дать разрешения "Полный доступ" для папки ftproot для моей учетной записи "Утилиты", и я установил флажок "Заменить все разрешения для дочерних объектов наследуемыми разрешениями от этого объекта", но он влияет только на текущие файлы. Когда новые файлы загружены, они снова не доступны моей учетной записи "Утилиты".

Я попытался пойти другим путем и поставить службу Cerberus FTP под учетной записью "Утилиты". Затем мне также нужно было предоставить разрешения учетной записи "Утилиты" для папки данных Cerberus в ProgramData. Все еще не повезло - после этой операции внутренний SOAP-веб-сервис Cerberus перестал работать (хотя, похоже, все остальное работает). Мне нужно, чтобы эта служба SOAP была доступна, поэтому запускать Cerberus FTP под учетной записью "Утилиты", похоже, не вариант. Если я не выясню, что еще мне нужно настроить для этой учетной записи "Утилиты", чтобы Цербер не жаловался.

Я предполагаю, что Цербер загружает файлы во временную папку, поэтому эти файлы получают разрешения для этой папки и сохраняют те же разрешения даже после перемещения в ftproot.

Какое было бы правильное решение для этого, которое предоставило бы FTP-серверу Cerberus и учетной записи "Утилиты" минимально необходимые разрешения для доступа к содержимому папки ftproot?

Дополнительная информация:

После некоторого расследования, как рекомендовали люди, я могу выбросить вывод icacls.

Вот вывод для папки, куда отправляются загруженные файлы:

C:\ftproot>icacls C:\ftproot\UserFolders\56
C:\ftproot\UserFolders\56 martinpc\Utilities:(I)(OI)(CI)(F)
                         BUILTIN\Administrators:(I)(F)
                         BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
                         NT AUTHORITY\SYSTEM:(I)(F)
                         NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
                         BUILTIN\Users:(I)(OI)(CI)(RX)
                         NT AUTHORITY\Authenticated Users:(I)(M)
                         NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)

Successfully processed 1 files; Failed processing 0 files

Все выглядит хорошо, у martinpc\Utilities есть права (I)(OI)(CI)(F), поэтому этот пользователь должен иметь доступ ко всем внутренним папкам и файлам, верно?

Но когда я смотрю на файл, который выдает "Доступ запрещен" при обращении к martinpc\Utilities, я вижу вот что:

 C:\ftproot>icacls C:\ftproot\UserFolders\56\uploaded.zip
C:\ftproot\UserFolders\56\uploaded.zip BUILTIN\Administrators:(I)(F)
                                       NT AUTHORITY\SYSTEM:(I)(F)
                                       BUILTIN\IIS_IUSRS:(I)(S,RD)
                                       martinpc\martin:(I)(F)
                                       martinpc\SQLServerReportServerUser$MARTINPC$MSRS10_50.MSSQLSERVER:(I)(RX,D,WD,AD)
                                       NT SERVICE\ReportServer$SQLEXPRESS12:(I)(RX,WD,AD)

Successfully processed 1 files; Failed processing 0 files

Для этого файла больше нет пользователя martinpc\Utilities. Если вам интересны эти ReportServer и IIS_IUSRS, у меня на компьютере разработки есть службы IIS и SQL Reporting. Но что интересно, так или иначе оба этих пользователя получают автоматические разрешения для этого файла, а мой специальный пользователь martinpc\Utilities - нет.

Затем я начал отслеживать, откуда берутся эти загруженные файлы. Я запустил Sysinternals Procmon, и вот что я увидел для процесса CerberusGUI.exe в тот момент, когда я загружал файл. Сначала был вызов CreateFile для пути C:\Windows\Temp\unq26B7.tmp, а затем после завершения загрузки я увидел SetRenameInformationFile ReplaceIfExists: False FileName: C:\ftproot\UserFolders\56\uploaded.zip

Теперь я попытался увидеть, что ACL имеет в C: \ Windows \ Temp:

C:\ftproot>icacls C:\Windows\Temp
C:\Windows\Temp CREATOR OWNER:(OI)(CI)(IO)(F)
                NT AUTHORITY\SYSTEM:(OI)(CI)(F)
                BUILTIN\Administrators:(OI)(CI)(F)
                BUILTIN\Users:(CI)(S,WD,AD,X)
                BUILTIN\IIS_IUSRS:(OI)(CI)(S,RD)
                martinpc\martin:(OI)(CI)(F)
                martinpc\SQLServerReportServerUser$MARTINPC$MSRS10_50.MSSQLSERVER:(OI)(CI)(RX,D,WD,AD)
                NT SERVICE\ReportServer$SQLEXPRESS12:(OI)(CI)(RX,WD,AD)

Successfully processed 1 files; Failed processing 0 files

Может быть, этот временный файл наследует разрешения от этой папки Temp, и когда Cerberus вызывает SetRenameInformationFile, файл по-прежнему сохраняет большинство старых унаследованных разрешений, хотя он был перемещен / переименован в папку C: \ ftproot?

Если я предоставлю пользователю martinpc\Utilities разрешения на C:\Windows\Temp, этого будет достаточно? Или, может быть, есть лучшее решение?