New password.txt requirement

So all my devs have come to me over the last few days confused by the new password.txt requirement to set a password for the server admin and I’ve had to walk them through getting it configured. Primarily because we run everything in CommandBox locally and this creates a barrier for some of the devs who (still) lack a full understanding of where Lucee servers reside under CommandBox.

This does, however, raise the question… why? Why has Lucee taken this step and introduced this barrier to entry? How many other engines (of any language) force a file system change to set a password?

I am of the opinion that it is not the job of the engine to enforce setting the password for the server admin. And, if someone feels strongly that it is the responsibility of Lucee to enforce this for security reasons, then this is probably the least user friendly way to accomplish it. Require localhost or a specific port to set the password, but not a file system change.

If devs and/or devops are too lazy to set a password for their admins when setting up the engine, then frankly they deserve to be hacked imho.

This just seems like a cannonball approach to solving the issue, which again shouldn’t be the responsibility of the engine, but of the individuals deploying it.

Can someone from the dev team please explain why such a heavy handed approach was taken here?

Thanks,
Denny

1 Like

Hi Denny, I’m not a Lucee dev, but I am the person who put in the ticket to make this change:

https://luceeserver.atlassian.net/browse/LDEV-926

I will add, they didn’t quite do it like I requested. I suggested they follow the pattern Jenkins uses whereby you don’t need to modify the file system, but you do need to copy a random string written to a file to prove you own the server.

The TL;DR; for CommandBox users is you can easily never see this screen by using a combination of CFConfig, DotEnv and a global .env file that has something like

cfconfig_adminPassword=mydefaultpass

this creates a barrier for some of the devs who (still) lack a full understanding of where Lucee servers reside under CommandBox.

Security and convenience are always on a continuum. To get more of one you give up some of the other. You can see in the ticket comments above that the feature originally told the user the full folder path on the file system to go to, but it was later reduced to not be the full path. In general, you can always find the root of a CommandBox server with

server info property=serverHomeDirectory

Why has Lucee taken this step and introduced this barrier to entry?

Because the default behavior was just horrible. And I mean that. Made me sick how horrible it was. Lucee was very lucky it was never exploited en masse.

How many other engines (of any language) force a file system change to set a password?

Technically all of them. You’d have to edit the password.properties file to change the Adobe password. The only difference is the Adobe installer forces you to set a password and the Adobe war file (and CommandBox CFEngine) come with a default password, which is only one step better, but still pretty insecure.

I am of the opinion that it is not the job of the engine to enforce setting the password for the server admin.

I would disagree there. It is the job of the server to be as secure by default as possible. The old behavior was a non-starter. You can see it took 4 years for it to get fixed and that was far too long. having an exposed admin on a server you just installed is simply not an option in today’s day and age. I don’t care for the workflow of the ticket, but then again I just use the CommandBox env vars or CFConfig.json to set my default password.

this is probably the least user friendly way to accomplish it.

I’m sure they would welcome suggestions to improve it. But at the end of the day, the only way you can prove someone owns a server is to ensure they have access to the file system.

If devs and/or devops are too lazy to set a password for their admins when setting up the engine, then frankly they deserve to be hacked imho.

Nope, we can’t get away with saying that. Look how that turned out for Adobe. It took them years of saying “it’s your job to lock down cfide to not get hacked” before they realized the crap would always flow back to them every time a CF server had a high profile hack, even if it was “their fault” for not locking something down manually. Secure by default is the only way.

This just seems like a cannonball approach to solving the issue, which again shouldn’t be the responsibility of the engine, but of the individuals deploying it.

See above.

Can someone from the dev team please explain why such a heavy handed approach was taken here?

Again, please provide a better way if you have one. But the fact is web-based admins are a pain and a primary point of getting hacked. Just leaving them open isn’t an option.

Thanks for the answers Brad. I’m afraid I didn’t have time to go look for the ticket on this one which is why I simply posted to get some answers, so thank you for taking your time to explain it in detail.

I have to concede that secure by default should be the standard and my remarks were not well considered before being made. I guess I was just taken aback by the sudden introduction of this barrier and the need to take time out of my day to explain to others how to handle it… and that I’m in the middle of trying to convince management to adopt Lucee over Adobe when this reared its ugly head… so I was ranting, as I am prone to do from time to time lol

I’d settle for a first login where a randomly generated password is written to a file, say password.txt, that has to be read by a human in order to login and is deleted upon first login (and a password reset forced at that point, perhaps). The need to go create a file and place it somewhere just seems abrupt to me and kinda poorly thought out. In short… your original suggestion as Jenkins does it would have been fine by me and I’d have never been here asking questions lol

I will make my notes on the ticket as well regarding that.

In the meantime thanks for the cfconfig advice - I will implement that in our processes.

– Denny

No worries, I understand the rant… the change is jarring the first time you see it. (And sorry if I sounded terse, I was running out the door to a Valentine’s party)

In reality, this will only be seen by CommandBox and J2EE/WAR users since everyone who goes through the installer will have a password set. I’ve also considered adding a default password of “commandbox” like I do for the Adobe war files. I really hate that though because a well-publicized default pass is just as insecure as no pass. But Adobe has no such “Please set your password” process (and with good reason). I suppose the upside of me forcing a default password on Lucee wars would be the convenience of at least being able to get into your dev site easily, but then I would have undone the entire purpose of the ticket I waited 4 years for in any case where someone threw a CommandBox Lucee site out in production without locking it down.

Getting off the weeds of CommandBox now, but I’m been mulling over some ideas of having a security profile or some such where you just tell CommandBox if you’re doing dev or production sites and then I can change what’s defaulted based on that. If I knew for sure you were using a site only for local dev, then I’d have no issue turning on directory browser, default passwords, open admins, etc, etc. But if CommandBox knew you wanted a production server, then all that would change. Anyway, if I can decide how to approach that in the future, it may help reduce some of this friction by being more aware of your needs.

1 Like

I have the same issue, to solve the problem use nginx as a proxy to block access to the admin console. Here is my config I use in docker:

default.config file below

server {
  listen 80 default_server;
  server_name _;
  index  index.cfm index.html index.htm;
  root   /var/www;
  server_name_in_redirect off;


  # Rewrite rules and other criterias can go here
  # Remember to avoid using if() where possible (http://wiki.nginx.org/IfIsEvil)
  # location / {
  #   try_files $uri $uri/ @rewrites;
  # }

  # Can put some of your own rewrite rules in here
  # for example rewrite ^/~(.*)/(.*)/? /users/$1/$2 last;
  # location @rewrites {
  #   rewrite ^/(.*)? /index.cfm/$1 last;
  # }

  #block/ignore requests for Application.cfc/cfm
  location ~* Application.cf[mc]$ {
    return 404;
  }

  #block/ignore requests for /lucee-server
  location ~* /lucee-server {
    return 404;
  }

  #block/ignore CFIDE requests
  location ~* /CFIDE {
    return 404;
  }

  location ~* /lucee/ {
    # allow 10.0.0.1; # Add your IP address here
    deny all; # block access
  }

  location ~* \.(cfm|cfc|cfr)$ {
      proxy_pass http://127.0.0.1:8888;
      proxy_redirect off;
      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-Host $host;
      proxy_set_header X-Forwarded-Server $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_connect_timeout 600;
      proxy_send_timeout 600;
      proxy_read_timeout 600;
      send_timeout 600;
  }

}

My Docker file

FROM lucee/lucee:5.3-nginx
# FROM llucee/lucee:5.3.5.87-SNAPSHOT-nginx

# NGINX configs
COPY web/config/nginx/ /etc/nginx/
# Patch Server
# COPY patches/ /opt/lucee/server/lucee-server/patches/
# Lucee configs
# COPY config/lucee/ /opt/lucee/web/
# Code
# remove hg it has a security vulnerability
run apt-get update -y
run apt-get remove --auto-remove mercurial -y
run apt-get purge mercurial -y
run apt-get install awscli -y
run sed -i 's/<cfLuceeConfiguration.*>/<cfLuceeConfiguration hspw="xxx" salt="4xxx" version="5.2">/g' /opt/lucee/server/lucee-server/context/lucee-server.xml
run sed -i 's/<cfLuceeConfiguration.*>/<cfLuceeConfiguration hspw="xxx" salt="xxx" version="5.2">/g' /opt/lucee/web/lucee-web.xml.cfm
run ls -la
ADD web/www /var/www
run ls -la /var/www

Notice how I update the web and server xml files. This is how I set the portal password. I have to ssh tunnel in on port 8888 if I want to access the console. My advice is to automate the config. This is 2020 the gui is not your friend! LOL So when your app spins up it should create the Database entries (DSNs), setup session storage (with database), config mail server (AWS SES) and output the logging to a centralize logger (cloud watch). This is how modern apps work. This should be the standard or similar.

I will publish/share all my configs when I get the complete solution to work on fargate. I hope this helps.

– Bill

but how do we even set password in password.txt and where should we keep the file, i am currently stuck in access the admin panel server|web due to password.

@utiliware, you should look into CFConfig. It will be a much cleaner way to manage your Lucee configuration instead of using sed commands to parse XML from bash! CFConfig is a CLI tool for managing Lucee (and Adobe) configuration from the commandline and allows handy import/export from JSON files. Ex:

box cfconfig set adminPassword=myNewPass to=/opt/lucee/lib/lucee-server/

(I made up that path, replace it with where ever your server context actually lives)

And to add to my note above about CFConfig, the CommandBox Docker images have CFConfig installed by default with built-in env var support so it’s even easier. Literally just this at the top of your image

ENV cfconfig_adminpassword myNewPass

@pratikb8

but how do we even set password in password.txt and where should we keep the file,

Write the file however you wish. Heck, you could just do this

echo myNewPass > /path/to/password.txt

Or use CFConfig to propertly automate all your configuration and then you never need to worry about that password.txt file again.

thanks for the fast response, @bdw429s
It worked, i installed cfconfig from commandbox and typed
ENV set cfconfig_adminpassword somepassword

ENV set cfconfig_adminpassword somepassword

@pratikb8 To be clear, what you typed above is probably not what you want. You combined an example of setting and environment variable in a dockerfile with an example of using the CommandBox CLI to directly invoke CFConfig. While typing a variation of what you have (notice the = sign)

env set cfconfig_adminpassword=somepassword

prior to starting a server IN COMMANDBOX would work, it

  • assumes you’re using CommandBox
  • Is only good for that Lucee version on that one server

That may be fine for you, but you may want to review.

1 Like

Hi all,

Thought I’d chime in with some other thoughts around this as I’ve been experimenting today with running Lucee within an embedded Tomcat instance, and hit an issue with this in combine with the password.txt feature.

Within my Gradle Java project (running through IntelliJ, fyi) I’m including Lucee as a java dependency. Due to this, the Lucee jar lives in the gradle cache, and therefore so does my lucee-server directory.

C:\Users\userLogin\.gradle\caches\modules-2\files-2.1\org.lucee\lucee\lucee-server\context

Dropping a file within this location is a bit awkward. I wasn’t even sure where to start but fortunately CFML came to the rescue…

writeOutput(getPageContext().getConfig().getConfigServerDir().toString());

Outside of a dev environment, the files are unpacked to the parent of my JRE runtime files which is a bit easier, but it’s still a bit weird. I’m not sure if there’s a parameter one could use to force the application to use a specific directory to output ‘lucee-server’, problem for another day!

edit: turns out I can just set this in the web.xml, or programmatically with embedded Tomcat…

ctx.getServletContext().getServletRegistrations().get(servletName).setInitParameter("lucee-server-root", serverRootDir);
edit 2: setting the parameter only works for ‘lucee-web-directory’ actually, maybe setting ‘lucee-server-root’ is no longer supported, but it does appear to be documented still

In terms of a better approach, I agree with Denard’s comment here.

I don’t have a personal interest in the change, as going forward I’ll be deploying custom config files which will override the default ones anyway. This post is mostly for the benefit of others, in case they hit this problem in an embedded Tomcat scenario. :slightly_smiling_face:

Cheers,
Glen

you can just set an environment variable, can’t remember it off the top of my head tho

1 Like

My update docker file… FYI Like that you are now considering devops in your updates. The whole admin config need to build devops in mind… Thanks again for the new feature!

FROM lucee/lucee:5.3.6.61-nginx

Lucee Set password

COPY config/lucee/password.txt /opt/lucee/server/lucee-server/context/

NGINX configs

COPY config/nginx/ /etc/nginx/

Lucee configs

COPY config/lucee/ /opt/lucee/web/

Lucee patches

COPY patches/ /opt/lucee/server/lucee-server/patches/

Lucee content

COPY www /var/www