Cronicle icon indicating copy to clipboard operation
Cronicle copied to clipboard

Running as root vs user

Open JasonSanDiego opened this issue 4 years ago • 22 comments

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?

JasonSanDiego avatar May 27 '20 05:05 JasonSanDiego

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

jhuckaby avatar May 28 '20 15:05 jhuckaby

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 [email protected] 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 .

JasonSanDiego avatar May 28 '20 17:05 JasonSanDiego

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

mikeTWC1984 avatar Jun 24 '20 21:06 mikeTWC1984

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...

schnurlosdusche avatar Aug 06 '22 10:08 schnurlosdusche

@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.

mikeTWC1984 avatar Aug 06 '22 13:08 mikeTWC1984

@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...

schnurlosdusche avatar Aug 24 '22 21:08 schnurlosdusche

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

image

image

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

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 ;)

schnurlosdusche avatar Aug 25 '22 06:08 schnurlosdusche

@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.

mikeTWC1984 avatar Aug 26 '22 02:08 mikeTWC1984

@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?

SprickW avatar Aug 23 '23 18:08 SprickW

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

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?

SprickW avatar Aug 24 '23 10:08 SprickW

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. 😁

Sorry, of course I meant "plugin".

SprickW avatar Aug 24 '23 11:08 SprickW

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.

matthenning avatar Oct 11 '23 21:10 matthenning

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.

SprickW avatar Oct 14 '23 12:10 SprickW

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.

matthenning avatar Oct 14 '23 16:10 matthenning

Just to prove I understand it right:

  1. You create a "normal" user.
  2. This user installs Cronicle - I didn't know that is possible.
  3. Any command that is passed to a Cronicle worker is executed in the context of this user - which is NOT root level.
  4. So commands that this user is allowed to execute in her own user context don't go to sudoers files?
  5. 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!

SprickW avatar Nov 19 '23 14:11 SprickW

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>.

matthenning avatar Nov 19 '23 15:11 matthenning

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 avatar Nov 19 '23 18:11 SprickW

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?

SprickW avatar Nov 20 '23 22:11 SprickW

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

matthenning avatar Nov 21 '23 10:11 matthenning