Score:0

Are there any potential pitfalls to changing the permissions of config files under /etc to a non-root user?

mx flag

There are various services which are being run on our machines, e.g. cassandra, datadog, etc.

Occasionally, we need to change the configuration, and we wish to automate the propagation of the config files and restarts.

We use Jenkins for automate the workflow for our application software, and were thinking of using this for services as well. We do not wish the server Jenkins runs on to have remote root (or even sudo) access to the host server.

I was wondering if we could safely change the owner of /etc/cassandra to cassandra, /etc/datadog to dd-agent, etc, because it would help us to automate. (Actually, is it recommended that such folders/files should be owned by the appropriate user, and that having root as owner is wrong?)

Score:0
kz flag

The idea of this directory has been that the /etc directory contains all system-wide configuration - opposed to each individual users configuration, which resides in most cases below $HOME/.config somewhere. Since the system-wide configuration affects all users, it is correct that those files are being owned by root.

Now, I do not know your system, but you are probably running cassandra etc once per system, and therefore you probably do not have the need for an individual users config file. I do not see any pitfalls in changing the ownership of those files / subdirectories except that it contradicts the way it has been designed. (As long as you do not change the ownership of the main /etc directory!)

Personally, I would setup an instance directory (in their home folder probably), and use the configuration stored inside there - but that is up to you.

Score:0
be flag

Root should not be owner of etc config files pertaining to applications. The elegant solution would be something like this: datadog application is run by the user datadog and config files is owned by datadog and group datadog. But now jenkins comes along and need to look/edit some files in /etc/datadog but perhaps not all.

So we create a new group called "datadogjenkins" and make BOTH datadog and jenkins a member of that group. Then we change the ownerGROUP for the files/folders jenkins need to read/write/execute to our new group.

Now, both datadog and jenkins can reach those assets. And neither of them need to escalate privileges to root. And we can keep jenkins out of what it doesnt need to see, in case jenkins were to be compromised.

Hope that explains it good enough.

ranban282 avatar
mx flag
My thoughts too. An unrelated question - typically we start services like cassandra using systemctl or service, which needs sudo (though it runs as the user cassandra, etc) - how to start services in a foolproof manner as the appropriate user.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.