0

I have set up Cerberus FTP server. By default, Cerberus FTP service runs under SYSTEM ACCOUNT. Also I have some console applications which run as scheduled tasks. They are running under a dedicated "Utilities" user account which has "Log on as batch job" permissions. These console applications take uploaded FTP files, process them and then move them to some dedicated archive folder.

The problem is that my console apps are throwing Security exceptions when trying to acces the uploaded files. I tried to give the Full control permissions on the ftproot folder for my "Utilities" account and I have checked that "Replace all Child object permissions with inheritable permissions from this object" checkbox, but it affects only current files. When new files are uploaded, they again are not accessible by my "Utilities" account.

I tried to go another way and put Cerberus FTP service under "Utilities" account. Then I also needed to give "Utilities" account permissions on Cerberus Data folder in ProgramData. Still no luck - after this operation, Cerberus internal SOAP web service stopped working (although everything else seems to work). I need that SOAP service to be available, so running the Cerberus FTP under "Utilities" account seems to be not an option. Unless I find out, what else do I need to set up for that "Utilities" account to stop Cerberus from complaining.

I guess, Cerberus is uploading files to some temporary folder and so those files get the permissions form that folder and keep the same permissions even after moved to the ftproot.

What would be the right solution for this which would grant Cerberus FTP server and the "Utilities" account minimal needed permissions to access the contents of the ftproot folder?

More information:

After some investigation as people here recommended, I can dump the output of icacls.

Here is the output for the folder where uploaded files go:

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

Everything seems nice, martinpc\Utilities has (I)(OI)(CI)(F) permissions, so this user should have access to all the inner folders and files, right?

But when I look at the file which throws "Access denied" when accessed for martinpc\Utilities, here is what I see:

 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

There is no more that martinpc\Utilities user for this file. If you are curious about those ReportServer and IIS_IUSRS, I have IIS and SQL Reporting services on my development PC. But what's interesting is, that somehow both these users get automatic permissions for that file, while my dedicated martinpc\Utilities user does not.

Then I started to track down, where do those uploaded files come from. I launched Sysinternals Procmon, and here's what I saw for the CerberusGUI.exe process at the moment when I was uploading a file. At first was a call to CreateFile for path C:\Windows\Temp\unq26B7.tmp And then after upload was complete, I saw SetRenameInformationFile ReplaceIfExists: False FileName: C:\ftproot\UserFolders\56\uploaded.zip

Now I tried to see, what ACL does the C:\Windows\Temp have:

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

Maybe that temp file is inheriting permissions from that Temp folder, and when Cerberus calls SetRenameInformationFile, the file still keeps most of the old inherited permissions although it's moved/renamed into the C:\ftproot folder?

If I give the martinpc\Utilities user permissions on the C:\Windows\Temp, will that be enough? Or maybe there is a better solution?

2
  • Please show us the output of icalcs for the folder and one of the problematic files.
    – Posipiet
    Sep 24, 2012 at 14:31
  • Added icacls output for all relevant paths. Sep 25, 2012 at 15:51

1 Answer 1

1

ACLs on folders have some properties that dictate how each permission will get inherited by each child-item. By using icalcs from Powershell to list the ACLs of a folder, you will see something like:

icacls foldername
NT-AUTORITÄT\SYSTEM:(I)(OI)(CI)(IO)(F) ...
  • (I) means "this is inherited for foldername from its parent"
  • (OI) means "this permission is meant to be inherited to child-files"
  • (CI) means "this permission is meant to be inherited to child-folders"
  • (F) means "Full Access is the permission to be handled this way"

You have to check if (OI) (CI) is enabled for the folder. You can set it with icalcs, see "icacls /?" on that, and check this article: http://support.microsoft.com/kb/318754/en-us

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .