Installing ColdFusion as non root user

[10xpg]

Hi everyone,

I’m trying to better understand how install ColdFusion on Linux as a non-root user.

From what I know, ColdFusion shouldn’t be run as root for security reasons — instead, it should run under a restricted “runtime user” (for example, cfuser or nobody). However, in our environment, system administrators don’t want developers like me to have sudo or root privileges, even for managing the ColdFusion service (start, stop, restart).

Here’s where I’m a bit confused:

• What’s the proper relationship between the runtime user that ColdFusion runs as and the user account that manages (starts/stops) ColdFusion?

• If ColdFusion is owned by a restricted runtime user, can another non-root user safely manage it?

• And how would this work for multiple ColdFusion instances (not just cfusion)?

I’d appreciate examples or best practices on how others have implemented this setup — especially on RHEL servers.

Thanks in advance for any insight or documentation links you can share!

[Dave Watts]

I read your question yesterday and decided to pass on it. I'd have to do a lot of typing to give you a decent answer, and I'm not even sure I have a decent answer to give you! But since no one responded, I guess I'll give it a shot. I can't promise this will be a complete answer.

You're right, ColdFusion itself should definitely not be run as root. But typically it's installed with an account that has root privileges, because that's how you register a service. I don't know how you do that without root privileges, but I think it can be done. I'd look beyond ColdFusion-centric stuff and just see if you can solve that problem first. You mention RHEL, so you might be using SELinux, which will involve extra steps. (Good luck!)

Each CF instance would be a separate service. I'm not sure how you'd install additional CF instances through the CF Administrator without CF having root privileges itself, but again I'm sure there's a way. It could definitely be managed by another user with the privilege to run the startup script - those privileges would typically be greater than the ones CF itself needs to run CFML code, which are pretty minimal - usually not needing to do anything but read those scripts. I don't think people generally use the "nobody" user anymore, but you could do that in the past. I wouldn't recommend that, though, since "nobody" could be used with other services and that kind of scares me a bit. The service startup script runs CF itself as the user you specified in the initial install: "cfuser" or "nobody" or whatever.

I did a little research by running the search query "how to start or stop a service in linux without root permission" and got different answers for systemd and systemv. I think RHEL uses systemd. Most of these answers involve using sudo, and changing the sudoers file to allow specific users to ONLY sudo into one account - but it wouldn't be root. This will sadly involve your system administrators, since you won't have the privileges to change the sudoers file yourself. Alternatively, those system administrators could create a group and allow that group to start/stop the CF service(s). Note that the RHEL answers require a subscription to access.redhat.com, but I think that's still free for Red Hat customers and partners.

[Charlie Arehart]

Yep, what Dave says, on why this was a challenging one to answer--especially succinctly, which is why I left it to others also rather than write a blog length reply. ;-} As always, Dave hit the key points in short order (as others here could, also).

I'll elaborate on one part: to your second bullet, this is where a group would help especially. You could consider putting the user running cf and the user wanting to manage things in the same group.

The first step would be deciding what file permissions are needed for the users/groups, and then running the cf service as that user/group. As Dave said, setting up services varies depending on the Linux distro (and even options within that).

Finally, you will find the cf lockdown guide covers some of the very matters we're now discussing. It's available online for any version of cf, easily found via searching. I'd recommend you check it out. And Pete (Freitag, who wrote it under Adobe's authority) may well have more to say here in reply. 

As you encounter more specific challenges, do let us know. 

[Dave Watts]

Pete (Freitag, who wrote it under Adobe's authority) may well have more to say here

Yeah, he knows more about Linux and a lot more about SELinux than I do!

[Charlie Arehart]

And he knows more about security than I've forgotten. 🙂

... while you, Dave, are on a pedestal in my mind that's too high to ever be eroded by any lack! 

[10xpg]

Thanks for the earlier insights, @Charlie Arehart and @Dave Watts 

As a follow-up, I’d like to dig a bit deeper into the non-root vs root installation setup for ColdFusion 2023 on RHEL.

What I’m still unclear on is this: although the Lockdown Guide says “Run the installer as the root user or by using sudo,” if a non-root installation is technically possible, what are the risks or tradeoffs involved in doing so?

I’d really appreciate any examples or best practices from others who’ve managed ColdFusion on RHEL servers.

Thanks again for the help so far!

[Charlie Arehart]

Let me try to help. I welcome clarifications from others or clarifying questions from you. 

1. The sudo command (in Linux, Unix, macOS) is used by a non-root user to temporarily elevate to having root privileges, to get something done. 

That's safer than logging in and running literally as the root user, as you could do things by mistake which could have wide-ranging impact, or you could fall victim to a vuln that now also would have that impact.

Of course, for an account to be able to DO that sudo command (or the related su), their account must be given that privilege by someone running as root (or already defined in sudoers). 

2. If it helps, the corollary in Windows is the "administrator" account, and how another account can be put in the Administrators group. One COULD just login as administrator, or by being in the admin group you may have noticed windows offer the option to temporarily elevate your privileges to perform some operation. 

(Also, FWIW, recent Windows versions even now allow one to enable sudo as a command, so you can intentionally run a given command with admin privileges--again assuming you're in the admin group.) 

3. So to your original question, that's why the installer could be installed as root or via sudo, to the same effect. There's one important additional point. 

Note that the Linux cf installer specifically ASKS what user to use to RUN cf, which can be different than the user INSTALLING it. That relates to the above, in terms of what permissions "cf" would then have. And one can create a user to run cf, giving it ONLY what permissions it needs to done what cf needs to do (discussed in the lockdown guide).

(In Windows, the cf installer sadly doesn't ask but just sets up a service that runs as the special "local system" account, available for such services. We have to change it to another account manually.) 

BTW, all this is also why one would NOT want to put the user running the cf service into sudoers (on Linux, or the 

Administrators group in Windows), as that would make it just as capable of causing trouble as if it WAS the root (or "administrator") account.

Does all that make sense, and help with your question? 

[10xpg]

Thank you once again @Charlie Arehart

I think I could have done a better job with my previous reply. What i actually meant was is it possible to install ColdFusion without having the root user involved in the setup, even before getting into the details within the installation like selecting a user to run cf.

[Charlie Arehart]

Yes, that was my point 3...which built on the previous two. 

[Dave Watts]

The root user will need to be involved initially, to configure the sudoers or groups or whatever you're going to use to avoid needing root yourself. The user who installs CF will absolutely need to have a specific set of privileges:

• create the CF directory, which is usually outside /home/{username}
• place the binary files into the directory
• create the web server connector
• edit the web server's configuration to use that connector
• edit the web server's configuration to specify the web root
• place the appropriate HTML, CFML, etc in the web root

(and probably some more I don't recall right now)

Users on an out-of-the-box Linux server don't have those privileges. On a web server running CF, it's critical to keep those privileges secure. If an attacker can edit the web server's configuration, that's a serious compromise. So, it's normal to allow only the root user to do that stuff. The root user could delegate that to a larger group of trustworthy and competent users, but they'd actually have to be trustworthy and competent!

[10xpg]

Thanks so much, @Charlie Arehart , @Dave Watts , really appreciate you both taking the time to explain this so thoroughly.

This has helped me understand better the reasoning behind using root (or sudo) during setup and how permissions need to be managed afterward. I’ll try a few configurations on my RHEL test environment based on your advice and see how things go.

I’ll circle back here if I run into anything interesting or unclear during the process. Thanks again for sharing your experience - it’s been super helpful!

[Dave Watts]

You're welcome, and good luck!