hi,
here’s a question about resetting files permissions on Ubuntu with cfexecute.
directory: /home/myuser/mydir/myfiles.csv
current file permissions:
root:root *.csv
desired file permissions:
myuser:myuser *.csv
shell command:
chown myuser:myuser /home/myuser/mydir/myfiles.csv
running the above shell command at command prompt works fine.
however, turning it into a shell script named “mysh.sh” containing the following content:
chown myuser:myuser /home/myuser/mydir/myfiles.csv
(then run chmod a+r to set globally executiable )
then run the shell script, it faild to be executed sucessfully,
err msg: “Operation not permitted”
I could “sudo mysh.sh” and then supply root password,
However, I need to execute this shell script via cf’s cfexecute,
that is,
any idea?
thks
Put the sudo in the shell script:
echo <password> | sudo -S chown myuser:myuser /home/myuser/mydir/myfiles.csv
HTH
Side note: This is pretty insecure, obviously. I believe you can encrypt the password and pass the encrypted version to sudo but ymmv.
– Denny
@ddspringle thanks for the idea. Yes, indeed I’m concerned about pwd. Just for the hack, how would we encrypt the pwd, I guess some algo that Ubuntu supports natively, would you mind pm me?
Thank you, I’ll look into it.
The better way would be to allow the lucee group / user to manipulate the file (s) in question versus passing a password to the environment & hoping you never suffer a beach.
Right. How via lucee code?
Why do you need to constantly change permissions on files?
Once permissions are set correctly, there should be no reason to constantly have to update file permissions.
Lets assume Lucee runs as “LuceeAPP” user with the group “LuceeAPP”
Lets assume that Lucee is intergrated with Apache, and Apache runs as “apache” in the group “apache”
Lets assume that “myuser” keeps touching, creating, modifying, downloading or whatever “myfiles.csv”
We will assume that FollowSymlinks is set in Apache configuration and that you are using some Debian version.
as root or sudo
ln -s /var/www/yourVhostorHTML/mydir /home/myuser/mydir/
That creates a link apache can follow and see
Next make sure that lucee, apache can manipulate that directory
usermod -a -G myuser apache
usermod -a -G myuser LuceeAPP
Now run your shell script using the path /yourwebroot/mydir/
As for the manipulation of files via Coldfusion / CFML / Lucee
cffile & cfdirectory are the tags you could use.
Lucee docker image. let me think… thanks.
I registered the issue w/ the docker containers running as root here - it didn’t get any traction.
The wizards at Ortus were more responsive:
And provided a “USER” option with the container, so you can deal with these sorts of issues. Follow their documentation to determine how best to do that.
With the containers I make, I generally roll my own container w/ a user with a uid of 1000 if I know it’s going to be used for local development, because if your VM has an unpriv user, and you’re the only user on it, it’s probably UID 1000.
1000% agree that instead of doing gymnastics with sudo, you should just set your permissions appropriately.
Another way to deal with it is to leverage SGID directories… It won’t reset the owner to root, but it WILL reset the group ownership to match the directory. That may be enough if your umask is set to something like 002 or 007 instead of the default of 022.
i.e.
mkdir /home/myuser/Workspaces
chmod g+s /home/myuser/Workspaces
When you write files into /home/myuser/Workspaces it will be chgrp’d to the user who owns Workspaces.
And since my original email response never made it to the list:
- a+r is READ, a+x is EXECutable
- The first line should tell linux what to use as the interpreter - so it should look like:
#!/bin/sh
chown myuser:myuser /home/myuser/mydir/myfiles.csv
Other comments - no matter how you encrypt your password, it will be passed unencrypted to sudo, so it can be intercepted.
If lucee is running unprivileged, the best bet is to use the same UID/GID as your dev user. (I believe in other threads I had recommended switching to CommandBox - if you used CommandBox on your host instead of a docker container, it WOULD be running unprivileged as your user account by default.)
If lucee is running as root, sudo is completely unnecessary, as is a password. Just chown and be done with it. But it illustrates that your code, i.e. Lucee, can change ownership of any file in your container AND any file exposed via a volume mount. It can also chmod anything, rm -rf anything, or do anything root can, which is a lot. Which is why it’s generally a bad idea to run internet accessible services as root unless it’s strictly necessary. Docker has also been known to have bugs (in runc, containerd or other pieces) that prevent security encapsulation and allow root escape. They fix them quickly… but that’s not the point.
if lucee is running unprivileged as someone OTHER than the UID/GID you want, you can use sudo and /etc/sudoers to indicate Lucee’s user doesn’t need a password to run chown. It’s better than running Lucee as root, but only slightly - you can control which commands can be run through sudo, but giving access to chown still exposes a lot of surface area.
@joe.gooch thank you very much for taking the trouble of resolving it. My ultimate solution would be an architectural upgrade, which will bypass file privilege manipulation entirely. Much appreciated.