Running as root vs user

JasonSanDiego commented 4 years ago

Have you considered making the docs more opinionated about running as root vs user? Also, a preferred way to install node? I love this project, but found myself spinning my wheels much more than I expected getting it configured.

In setting up Cronicle, I easily spent >50% of the time battling Linux and wishing the docs were a little more specific.

Specifically the questions/issues that came up while configuring it (on Amazon AMI):

Is it better to run Cronicle as root or user? I ran the setup as root. I think this was required to put it in /opt, but don't remember. An opinion in the docs would help
Used nvm to install node as root. Then found it was difficult to get my environment just right to run the jobs I was previously running in my user cron
Start over, use nvm to install node in my home dir
Can't run cronicle, because I installed it as root; change owner on everything
Figure out how to write a systemd service file that will use the node binary installed in my home .nvm directory (came across #138 but this seems to be for using system node, not nvm installed node). Ended up setting the ENVIRONMENT parameter to set my path.
Still not sure what the recommended path is if I have some jobs I need/want to run as root and some as user. With cron, I schedule most things as my user and just go to the root cron for the rare occasion. What's recommended here, considering Cronicle doesn't have a "run as user" configuration?

jhuckaby commented 4 years ago

I'm very sorry you had trouble installing it. This will all be fixed in the next major release.

JasonSanDiego commented 4 years ago

No need to apologize. You’ve done a great job with this project and it’s a great tool. I hope you will find the time to maintain it for a long time to come. I just found that as effectively a first-time node user (despite using a LOT of python projects), it was more complicated to set up than I expected.

Looking forward to see what the new version brings.

On Thu, May 28, 2020 at 8:25 AM Joseph Huckaby notifications@github.com wrote:

I'm very sorry you had trouble installing it. This will all be fixed in the next major release.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jhuckaby/Cronicle/issues/289#issuecomment-635419249, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKA3SQMSTSOXK2KMGCXGK3RTZ7ALANCNFSM4NLZU6YA .

mikeTWC1984 commented 4 years ago

I think running cronicle as root is not good idea. I also don't see out of the box option to run it as non-root. I think installation should create some group for users who can run cronicle

schnurlosdusche commented 2 years ago

I was using cronicle on my QNAP for a while, switched over to VMWare/ESXi and use cronicle on a CentOS machine. Having trouble starting cronicle as user and not root.

I love this tool as it makes life so much easier ! Thank you for your really great work.

Will try to figure out, how to run this as a user...

mikeTWC1984 commented 2 years ago

@schnurlosdusche I think the problem with non-root is that you won't be able to spawn child job as different user. Over time I came to conclusion that it's better idea to run cronicle as root, but set plugin to run as non-root. This way you can protect some sensitive data from exploring by shell plugin users.

schnurlosdusche commented 2 years ago

@mikeTWC1984 Sounds good. Will give that a try... I am not feeling very happy with the fact to let root connect via ssh to run an rsync job. But to be honest, its in my local network. But nevertheless, using root for things like this is always not my prefered way.

I am sure to use cronicle for the next decades to come. So I guess I will see the further development in newer versions...

dheise-rheinenergie-trading-com commented 2 years ago

We also run cronicle as root on our servers but cloned the shell plugin multiple times and set diffent users for them.

@schnurlosdusche : schöne Grüße aus Köln nach Köln ;-)

schnurlosdusche commented 2 years ago

TL;DLID (Too long, did'nt look in detail) .... well, that makes absolutely sense and I should have found that if I had looked in more detail of all possible settings

@dheise-rheinenergie-trading-com Grüsse zurück ;)

mikeTWC1984 commented 2 years ago

@schnurlosdusche If you don't share access to cronicle much I guess you can run it as non root. Root helps to control access to certain files, if its not an issue than non-root is just fine. Although it might be a good idea to run it in container. You can be a root being in the send box at the same time.

SprickW commented 1 year ago

@dheise-rheinenergie-trading-com Cloning the plugin makes sense to me. But I don't see the option to enter the secret (password).

Any hint?

dheise-rheinenergie-trading-com commented 1 year ago

you don't need a password. the root user can impersonate every local user without having the password.

SprickW commented 1 year ago

OK, if the default is running everything with root permission ... we have to be careful. That's what I suspected but did not find in written form.

Wouldn't it then not be a good idea, to restrict specific users to the use of specific profiles (like what ist currently possible for categories and server groups?

dheise-rheinenergie-trading-com commented 1 year ago

Do you mean "plugin" instead of "profile"? I agree that it would be a good idea. Fortunately, this is not a major problem in our enviroment. Only admins have access to cronicle. And we are always careful. 😁

SprickW commented 1 year ago

Sorry, of course I meant "plugin".

matthenning commented 1 year ago

I've run into the same question during the last days and resolved to running Cronicle with a dedicated user. Every action has its own bash script which then has an entry in the sudoers file so Cronicle can run it as root. As long as the Cronicle user has no write permissions on the bash scripts it should be pretty solid.

SprickW commented 1 year ago

I've run into the same question during the last days and resolved to running Cronicle with a dedicated user. Every action has its own bash script which then has an entry in the sudoers file so Cronicle can run it as root. As long as the Cronicle user has no write permissions on the bash scripts it should be pretty solid.

Could you describe your solution in more detail? What does "running Cronicle with a dedicated user" mean? What does "bash script which then has an entry in the sudoers file" mean? I assume that with "Cronicle user" the ops people are meant that work with the Cronicle GUI? If so I'm fine with security as long as they are not able to edit the bash scripts.

matthenning commented 1 year ago

I created a new user on the OS and installed Cronicle to its home directory. Simply run the install instruction as the new user. Then I created a bash script for every task Cronicle is supposed to fulfil, mainly backups in my case. All these scripts have an entry in the sudoer file, so the Cronicle user is able to run them with root permissions.

06:05:10 root@server ~ → cat /etc/sudoers.d/cronicle
cronicle        ALL=(root) NOPASSWD:    /home/cronicle/scripts/mysql_backup.sh
cronicle        ALL=(root) NOPASSWD:    /home/cronicle/scripts/nginx_backup.sh

Make sure the scripts can only be written to by root, or whatever trusted user other than Cronicle.

Finally you go into Cronicle, create a new schedule, e.g. for your MySQL backup, select the plugin "Shell script" and enter the script in the plugin source:

#!/bin/bash

sudo /home/cronicle/scripts/mysql_backup.sh

Remember to the sudo.

SprickW commented 12 months ago

Just to prove I understand it right:

You create a "normal" user.
This user installs Cronicle - I didn't know that is possible.
Any command that is passed to a Cronicle worker is executed in the context of this user - which is NOT root level.
So commands that this user is allowed to execute in her own user context don't go to sudoers files?
Single commands that need root access are authorized by being added to the sudoers files, so execution by Cronicle is limited to these commands.

Sounds very much like a workaround. But does not allow automation by different "technical users" as there is only this one user that can be used on that machine.

But if the answer to question 4 = True - then I may be fine.

Actually I don't like it, but if this is the only way to go ...

Tx 4 the help!

matthenning commented 12 months ago

You can sudo as any user as long as there is an entry in the suders file. So you could very well add multiple users with different permissions and execute scripts in their context with sudo -u <user> <command>.

SprickW commented 12 months ago

My intent goes the other way round: I want to avoid execution of application programs with root access, but support more than one of such users.

So I assume by your answer, that the answer to question 4 is "yes" which is fine for me.

SprickW commented 12 months ago

I created a new user on the OS and installed Cronicle to its home directory. Simply run the install instruction as the new user.

Did so without using "sudo node", but then curl -s https://raw.githubusercontent.com/jhuckaby/Cronicle/master/bin/install.js | node results in ERROR: The Cronicle auto-installer must be run as root.

So possibly you used some other way for installation?

matthenning commented 12 months ago

You can install it manually, see the docs: https://github.com/jhuckaby/Cronicle/blob/master/docs/Setup.md#installation

mkdir -p /opt/cronicle
cd /opt/cronicle
curl -L https://github.com/jhuckaby/Cronicle/archive/v1.0.0.tar.gz | tar zxvf - --strip-components 1
npm install
node bin/build.js dist

I installed it to the cronicle user's home directory but it's really up to you.l

zenithyr commented 4 months ago

Along the same page, I spent an hour on figuring out where nvm/node should be installed to support multi-user. The installation guide points to node.js, which defaults to ${HOME}/.nvm. This causes permission issues if you need different user account.

While the Cronicle installation guide suggest to install it onto a "standard location", I can't find how. So I came up with

su -
export XDG_CONFIG_HOME=/opt
wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh > install.sh
bash install.sh

jhuckaby / Cronicle

Running as root vs user #289