Access denied and cache?

Hi Terry,

There are no users with the names mentioned.

I dug the access rights and Lucee was installed without creating a specific user. The service runs with the user Local system account and System has full access to the server’s disks, both disk C where Lucee is located and disk T where the CFML application is located.

lucee-properties

c

t

I have the impression that the service currently has too many rights. So is it really a right of access problem?

It doesn’t seem safe to me to use the Local system account, so we’ll fix it by creating a specific user for Lucee’s service. Let’s call it LuceeServiceUser. I have searched the documentation and there is no information on which folders the LuceeServiceUser should have access to. I’m assuming it’s C:/Lucee and the wwwroot on the T. I tested it on the development environment and it looks correct.

The documentation is empty (to-do list)

I found this video : How to install Lucee on Windows 2019 Server IIS: Step 4 - Grant Lucee access to IIS webroots - YouTube

Thank you for your help!

1 Like

You are correct, the system usually has far more permissions than what should be allowed for a production site.

Sorry for assumption, anything I see above H I typically use as a network drive.

First off, @pfreitag has some great tools and insite in locking down a CF box.

That being said

This is the general path We follow for Windows in production

Update everything - Web/ Os/ Apps
Configure Windows Firewall to block everything
Turn off RDP
disable and remove all vendor software not needed to run the app / server
ACF / Lucee installed on its own partition or drive
all static assets on their own partition or drive
all other web app items, on their own partition or drive
USE NTFS for fine grained file permissions
remove 8dot3 naming
1 user per application - kiss naming (Keep it simply short) CFLucee for Lucee, CfPython for Lucee python worker, python for python worker, so on and so forth
disable password changes
disable password expiration

For IIS / APACHE
create service user for either / or both as needed
remove users from any per-defined groups
disable inheritance for created users on newly defined folders

for LUCEE USER and others, change permissions from “Full control” to
read/execute
List Folder Contents
Read
(Write) if needed

For IUSR / Pool Users
Read & Execute
List Folder Contents
Read

IIS
host-headers on
directory-browsing off
application pool identity for for all applications
unique application pools for all sites
(if you can, 1 site per host)
application pool identity’ is configured for anonymous
disable WebDav
global authorization rule’ is set to restrict access
‘maxAllowedContentLength’ is configured
Ensure ‘maxURL request filter’ is configured
non-ASCII characters in URLs are not allowed
HTTP Trace Method’ is disabled
Unlisted File Extensions are not allowed
Handler is not granted Write and Script/Execute
notListedIsapisAllowed’ is set to false
‘notListedCgisAllowed’ is set to false
Default IIS web log location is moved (outside web and sysroot)
Advanced IIS logging is enabled
Dynamic IP Address Restrictions’ is enabled
‘ETW Logging’ is enabled
Configure Request Filtering
block all /CFIDE
/LUCEE/Administrator
/Lucee/WebContext
/CPANEL
/WEB-INF
/.git
/.ht*
/rest
/lucee

There are many others here, go wild if you get bored but as a base

Move the Lucee WEB-INF outside root
Remove any unused application pools
Change .Net Framework to “no managed code”
Remove ASP.NEt ISAPI filters
Remove any unused handler mappings
Bind and restrict Lucee administrator to 127.0.01 / localhost
Update java to the latest supported java by lucee and point config to lucee path

When ever possible use an external Firewall for handling encryption

There are some other steps, but this should get you started.

1 Like

Hi,

I have a new hypothesis. To put you in context, we migrated from ACF to Lucee on an emergency basis. We have not yet had time to restore all our tools to our standard development and production environment (sftp, gitlab, vscode). While waiting for the situation to be restored, I only carry out small, simple updates by going directly to the server and I open the files with Notepad ++. I know very well that this is not ideal, but it helps us out for the moment. Except that the last time, the Access denied error was on the /fr/intranet/pages/index.cfm file that I had not modified the day the error occurred. Except that recently, when I opened Notepad ++ again, I saw that a old tab was open on this specific file. I have also noticed that Access denied error often occurs on files that I modified in the previous days/weeks. It lets me think that Notepad ++ locks the files and prevents Lucee / Java from reading them to put the template in memory. I might be totally wrong too, but that doesn’t seem entirely illogical to me.

Assuming that’s it, however, I can’t explain why restarting Lucee would fix the lock situation.

I also tried to reproduce the situation on our development environment using Notepad ++ as admin, as not admin, by letting the tabs opens or not, but failed to reproduce the problem.

I still keep this idea in mind.

Thank you for all this checklist! I will follow it.

1 Like

@TonyMonast I’m the creator of those access videos on YouTube. I’ve added those to the docs some time ago. Just chiming in here to share some information. Don’t know if it will help, but at least mentioning it shouldn’t hurt.

We have also migrated, but from Windows 2012 to 2019. On win 2012 the Lucee service also ran with “Local System”. It was terrible security practice. I’ve decided to switch the user to “Local Service” which is also the MS recommended user to use for this type of services. Tomcats tomcat9.exe/service.bat also installs this user by default and the Lucee installer does it also.

When we switched OS lots of issues came up. Mostly everywhere where we used CFML in a more integrated way of using specific OS stuff or executing third party software tools. I’ve faced lots of issues where I never had any problems, because of Lucee running as “Local System”. This all is really freaking finetuning and depends on your specifc setup. But as of today, I’d really run Lucee only with “Local Service”, unless you can’t circumvent it anymore.

This all needs to be tested very carefully before switching, it’s not something you should do quickly over night.

2 Likes

Thanks for the information. I will take your advice. I quickly tried to change the user for Lucee on our dev environment, but FusionReactor stops responding afterwards. I wanted to add the user to the FusionReactor folder, but Windows generates an error that it cannot apply the rights to all files. I’ll have to look into this and come back if I can’t resolve this myself.

1 Like

We’re having the same problem. It’s not a direct permissions issue - everything ran fine for a year, and then over the weekend, we started getting the same (or very similar behavior):

  1. Any files newer than 3 days ago throw a 500 error, although they we working fine yesterday, etc.

  2. Any existing working file that gets modified in any way - open it up, and a period, close it up - now throws a 500 error.

  3. Open the same file up, and remove the period, close it up again - now it works fine again.

This really smells like a weird caching error, but the logs are calling it an 'Access Denied" error, regardless of whether the file requested is a new file, or an existing file that was just edited. We haven’t made any cache changes, and I’m reticent to click any ‘clear cache’ buttons in the admin, because overall, the primary site and processes are live and working properly. I want to avoid experimentation if possible - any ideas?

please always mention which lucee version :slight_smile:

I wonder if it could be a file locking issue?

Before, when I had the problem, note that even if I edited the file again, the problem persisted. I had to restart Lucee/Tomcat to get rid of the Access denied.

On our side, it has been stable for several months. The only time I experienced this problem again was when I was uploading a file with vscode via sftp. The upload was taking a while and when I hit the page during that time, I got the Access denied error. But when the upload completed successfully, the page started working again. In my case, Lucee checks for changes in files on every request.

I’m not very familiar with how the cache works under the hood, so I have a guess that’s probably stupid, but is it possible that…

  1. Something happens on the file (upload, editing, antivirus software scanning, whatever)
  2. The user hit the cfm page during this time and the cfm page return Access denied because another process work on the file
  3. Lucee put in cache the result of this cfm page (it cache Access denied)
  4. The other process finish his job on the file and release it. It should not return Access denied anymore, but…
  5. The user hit the cfm page and Lucee return the cached version (Access denied)
  6. The programmer sits with a blank stare wondering why this only happens to him.