How to use cfexecute for Ubuntu internal commands?

How do we use cfexecute to run some internal command in Ubuntu environment? Please see below, thanks

<cfset sid = "328">
<cfset hashvalue = "U2D7W83IWNSWIE6723">

<!---  deposmeta.json exists already but may be empty or not --->
<cfexecute name="cmd" arguments="echo #sid#:#hashvalue# >> deposmeta.json"></cfexecute>

replacing >> with >> does not help neither.

The above code failed to append but did not generate any error. It’s lucee4:latest docker image on ubuntu 16.04 LTS.

On a second thought,
what is we turn the “echo #sid#:#hashvalue# >> deposmeta.json” part into a shell script that accepts two parameters and then use cfexecute to call this script and pass along the two values to it? But I’m getting rusty on shell scripting, that is, how to accept two parameters…

When needing to use cfexecute with complicate bash syntax in the past I have worked around the nuisances of cfexecute by using cfml to dynamically create a bash script using cfsavecontent and cffile. I then executed the bash script with cfexecute. (Also simplifies debuggin as you can also run the generated scripts as the lucee user on the command line). Just be sure to use some unique identifier for the filename to avoid race conditions and place the files somewhere like tmp where they get cleaned up.

Thanks for the idea. I’m afraid creating a bash script dynamically would fail in my case because it involves file creation and file creation has proven consistently failing in my case.

the 5.3.2.35 snapshot includes a rewrite of how cfexecute handles arguments

CFEXECUTE arguments does not properly handle arrays
https://luceeserver.atlassian.net/browse/LDEV-2014

Any reason you are still using the ancient Lucee 4 version?

Lucee4 docker image was released some time in 2018, why did you label it as “ancient”?

The key issue here in my case, file creation/writing/appending issue, CFFILE or CFEXECUTE are simply methods to get it done, but failed, it seems rights/permission were not set up properly, the core developers of Lucee4 docker image need to step in and share some insight and help to fix it.

Lucee 4 is completely end of life, the last Lucee 4 release in 2018 was just a minor security bug fix
https://lucee.daemonite.io/t/end-of-life-for-lucee-4-5/4093

Both the traditional and docker download pages for 4.5 need to be updated to indicate this, I requested them to be updated back in July 2018, but it hasn’t happened yet (waves to @IamSigmund)

If you find a problem with Lucee 4, it’s simply not ever going to be addressed.

If it’s still a problem with Lucee 5, then you can search for and file add a comment to an existing bug.

Your permissions problems maybe most likely be something to do with your server, rather than a problem with Lucee itself

I appreciate your thoughtful update.

Regarding “Your permissions problems maybe most likely be something to do with your server, rather than a problem with Lucee itself”, my “server” is Ubuntu 16.04 LTS, the user account for pulling lucee4 and build and run lucee container is a part of sudo group, so, it seems to have plenty of rights/privilege, what else could be source of problem?

let’s keep that discussion in the other thread you created?

Just FYI, I’m guessing you have the same problem here. It probably did SUCCEED writing to the file, but inside the container, on a copy of your files, without a volume mount.

Just another thing to point out here…

Lets assume your sudo group is gid 27 like mine is… Lets also assume your user is in the docker group, in my case group 999.

The only thing these groups grant are:
Ability to read/write files on the filesystem based on the group RWX bits, for my primary group AND groups 27 and 999.

That’s it. No additional permissions, no ability to write files anywhere on the filesystem, nothing else.

In the case of docker, you get the ability to use docker because of this:

$ ls -l /var/run/docker.sock
srw-rw---- 1 root docker 0 Jan 20 09:46 /var/run/docker.sock

The control socket that the docker DAEMON uses is owned by the docker group, and if I’m in that group I can send the daemon commands. This is a firm distinction because, for instance, I can’t muck around in /var/lib/docker/ even though I have group 999. Only the daemon can do that, based on the filesystem permissions. So I gain the ability to accomplish additional functionality by convincing a program that HAS that permission to do it for me, and display the result.

Again, this may seem nitpicky but it makes all the difference when problem solving. A user in the sudo group is still just a user, who still has access to just their files and folders. But if you RUN the sudo command, based on the rules in /etc/sudoers, sudo can be convinced to allow you to run programs with elevated permissions, which may or may not be limited. (For instance, I’ve used sudo to create limited admin groups that can only reboot or halt a server, or restart services, not muck around in internals)

In the context of lucee, the sudo group would only be relevant if:

  1. You were running the lucee process through sudo… in which case the gids and user account are no longer relevant because lucee is actually running as root… sooooo.
  2. You were running sudo through cfexecute - in which case the lucee process would leverage the sudo gid to gain additional privileges and do things.

(Of course in your example, even sudo echo a:b >> file would not work because if you’re running on a shell, the redirection is redirecting from the parent shell, so you’re running sudo to echo, which is silly, and the redirection still happens as your user. You’d have to do the uglier sudo bash -c ‘echo a:b >>file’. or some such thing which is why I hate cfexecute in the first place because a) you shouldn’t assume you have a shell in the mix unless you explicitly call it, and b) with all the single and double quote sets it’s very easy to get wrong)

I forgot how many tangents deep I went but the TL;DR is that the sudo group in this case in completely irrelevant. :slight_smile:

1 Like

interesting topic