I want to make sure that while compiling as root nothing will break down inside the machine.
I want to compile software on a Xeon SERVER. The basic issue is that there is a recommendation to not compile it as a root user.
I have compiled software as a root user more then once and I am not sure why would there is a need to run it as non-root user?
I have taken a look at the /proc/ FS but I do not see anything that can harm anything yet.
From my aspect it's just background of electricity noise.
I will be happy to hear from experience of others about it.
Thanks, Eliezer
On Thu, 02 Jan 2014 01:53:09 +0200 Eliezer Croitoru wrote:
I have compiled software as a root user more then once and I am not sure why would there is a need to run it as non-root user?
1. Bad Things™ happen sometimes. If you are root, Worse Things™ can happen than what might happen if you are not root.
2. It's just basic common sense to use the root access to the minimum extent possible. (See Step 1)
3. Since it's not necessary to compile software as root -- goto Step 1.
On 1/1/2014 3:53 PM, Eliezer Croitoru wrote:
I have compiled software as a root user more then once and I am not sure why would there is a need to run it as non-root user?
Its the principle of least privilege.
You don't need to be root to compile software, or to test software in a local directory, you only need root privileges to install it to a system directory. When you're developing, building, testing software, there's a very good chance of something going wrong, so if you are running as a non-root user, the potential damages are minimized.
Hey John,
Thanks!
On 02/01/14 02:14, John R Pierce wrote:
Its the principle of least privilege.
You don't need to be root to compile software, or to test software in a local directory, you only need root privileges to install it to a system directory. When you're developing, building, testing software, there's a very good chance of something going wrong, so if you are running as a non-root user, the potential damages are minimized.
OK so as long as I can understand the meaning of compiling as non-root user is to be careful with your system.
I would say that my conclusion is that if there is a very big system it is better to let the root user which understand the meaning of this system and to operate it.
A simple testing machine which has error correction mechanism in it should be OK.
I can see couple issues from my mind and vision but it seems like most software in CentOS will be safe to be compiled as root user.(I am testing a tiny simple piece of software)
To corrupt a system in a level which it cannot be recognized that you have changed it you must be something like GOD or something in the same level.
Thanks Again, Eliezer
On 01/01/2014 06:25 PM, Eliezer Croitoru wrote:
Hey John,
Thanks!
On 02/01/14 02:14, John R Pierce wrote:
Its the principle of least privilege.
You don't need to be root to compile software, or to test software in a local directory, you only need root privileges to install it to a system directory. When you're developing, building, testing software, there's a very good chance of something going wrong, so if you are running as a non-root user, the potential damages are minimized.
OK so as long as I can understand the meaning of compiling as non-root user is to be careful with your system.
I would say that my conclusion is that if there is a very big system it is better to let the root user which understand the meaning of this system and to operate it.
A simple testing machine which has error correction mechanism in it should be OK.
I can see couple issues from my mind and vision but it seems like most software in CentOS will be safe to be compiled as root user.(I am testing a tiny simple piece of software)
To corrupt a system in a level which it cannot be recognized that you have changed it you must be something like GOD or something in the same level.
Things like, if the RPM does not properly config the target during the build, instead of installing into $RPM_BUILDROOT and trying to package up the RPM, it might install it to /usr/lib/ accidentally, etc.
Some software is written poorly.
If we are talking CentOS / Red Hat / Fedora type packages then most of the time nowadays those SRPMs should be built inside of mock anyway to get a clean buildroot.
I am obligated to say: "How would you expect a 100MB of code to be mocked?"
What would be a clean buildroot for? If somebody wrote the software and decides what and how to install he should at least be familiar with the basic structure of the OS unless it's not possible to find somebody that actually knows the structure of the OS.
Eliezer
On 02/01/14 16:21, Johnny Hughes wrote:
If we are talking CentOS / Red Hat / Fedora type packages then most of the time nowadays those SRPMs should be built inside of mock anyway to get a clean buildroot.
On 03.Jan.2014, at 00:25, Eliezer Croitoru wrote:
I am obligated to say: "How would you expect a 100MB of code to be mocked?"
We are talking mock the software for building rpms in a chroot, aren't we? http://fedoraproject.org/wiki/Projects/Mock
On 02.Jan.2014, at 00:53, Eliezer Croitoru wrote:
I want to make sure that while compiling as root nothing will break down inside the machine.
I want to compile software on a Xeon SERVER. The basic issue is that there is a recommendation to not compile it as a root user.
Actually I would go even further and not recommend to have a compiler installed on a server.
I have compiled software as a root user more then once and I am not sure why would there is a need to run it as non-root user?
I have taken a look at the /proc/ FS but I do not see anything that can harm anything yet.
From my aspect it's just background of electricity noise.
An example:
imagine a Makefile with a clean target
$BUILDDIR=something clean: rm -rf $BUILDDIR/*
a bug in the configure script could lead to an empty $BUILDDIR in the Makefile. What do you think happens when you type
# make clean
Hey Markus,
On 04/01/14 18:37, Markus Falb wrote:
An example:
imagine a Makefile with a clean target
$BUILDDIR=something clean: rm -rf $BUILDDIR/*
a bug in the configure script could lead to an empty $BUILDDIR in the Makefile. What do you think happens when you type
# make clean
A script runs and do all sort of things on the way.. for example: makefile ##start install: echo "Listing the dev directory with couple nice things in it" ls -lh /dev/
clean: echo "I would like to remove the dev directory but it seems pointless to me" rm -rI /dev/* ##end
Will help me understand the meaning of this file. what can we do in order to prevent such actions? Would selinux would help in this specific case? usually I remember that chroot should help to prevent an issue with it.
Thanks, Eliezer
On 05.Jan.2014, at 16:08, Eliezer Croitoru wrote:
On 04/01/14 18:37, Markus Falb wrote:
An example:
imagine a Makefile with a clean target
$BUILDDIR=something clean: rm -rf $BUILDDIR/*
a bug in the configure script could lead to an empty $BUILDDIR in the Makefile. What do you think happens when you type
# make clean
A script runs and do all sort of things on the way.. for example: makefile ##start install: echo "Listing the dev directory with couple nice things in it" ls -lh /dev/
clean: echo "I would like to remove the dev directory but it seems pointless
Please do not tell me that you haven't seen projects that do the build outside the source directory
/dev/ Makefile build/ src/
I didn't meant to remove /dev, I am not dumb.
to me" rm -rI /dev/* ##end
Will help me understand the meaning of this file. what can we do in order to prevent such actions?
Would selinux would help in this specific case?
Please remember that my example was not about removing /dev/* but about removing /* , so why just not building as root?
usually I remember that chroot should help to prevent an issue with it.
Hm, where to draw the line between prevention and mitigation? Anyways, do not build on the target machine, e.g. your production server. It does not really matter in many cases if your development environment is separated by a chroot or a virtual machine or a whole physical machine.
Use software versioning software Make Backups Be prepared to recreate your development environment.
Even if you easily can recreate the development environment, maybe diagnosis plus recreation takes still more work than not building as root in the first time.
Anyways, looking at the Subject of this thread I have no clue what you are after. Even root can not do kernel level operations. Only the kernel can do that, can't it?
On 05/01/14 19:32, Markus Falb wrote:
Would selinux would help in this specific case?
Please remember that my example was not about removing/dev/* but about removing /* , so why just not building as root?
Well I am building as root when I understand it is safe to do so.
usually I remember that chroot should help to prevent an issue with it.
Hm, where to draw the line between prevention and mitigation? Anyways, do not build on the target machine, e.g. your production server.
OK.
It does not really matter in many cases if your development environment is separated by a chroot or a virtual machine or a whole physical machine.
OK
Use software versioning software Make Backups Be prepared to recreate your development environment.
OK
Even if you easily can recreate the development environment, maybe diagnosis plus recreation takes still more work than not building as root in the first time.
This is the basic argument. I encourage to not build as root since it is better to be safe and steady then fast and reckless.
Anyways, looking at the Subject of this thread I have no clue what you are after. Even root can not do kernel level operations. Only the kernel can do that, can't it?
There are patches for the kernel to allow user-land almost direct access to the kernel resources. In the above case it is better to understand first that there is a possibility in this level. The kernel can be patched to send into the\an user-land software data. I do remember that it was done for iptables extensions.
I am sure it is not recommended and it is not the best way to operate a system at all.
Eliezer
-- Markus
On Sun, Jan 05, 2014 at 11:54:12PM +0200, Eliezer Croitoru wrote:
Well I am building as root when I understand it is safe to do so.
This is the point; unless you wrote every line of code then you _don't_ know it's safe.
If I sent you a random script, would you run it as root without checking every line of code first? I'd hope not.
Have you checked all 10,000+ lines of code in all the "configure" scripts and Makefiles ?
If (and only if) you've written every single line of code then... Ok, do it as root. But if you've done that then you might as well write the build process so you _don't_ need root. "Best practices" says root should be an exception rather than the norm.
On 1/1/2014 6:53 PM, Eliezer Croitoru wrote:
I want to make sure that while compiling as root nothing will break down inside the machine.
I want to compile software on a Xeon SERVER. The basic issue is that there is a recommendation to not compile it as a root user.
I have compiled software as a root user more then once and I am not sure why would there is a need to run it as non-root user?
I have taken a look at the /proc/ FS but I do not see anything that can harm anything yet.
From my aspect it's just background of electricity noise.
I will be happy to hear from experience of others about it.
The basic issue is limiting your exposure in the case of a problem. As long as everything works and is programmed properly, you can do whatever you want as root. But as soon as there is a problem, there can be huge consequences.
The root user has access to everything on the server. So a typo in a program/makefile/command has the possibility of bringing down the whole server. On the other hand, if you are logged in as a normal user, then the damage is limited to your directories.
Best practices say that you should do everything possible as a normal user. Root should only be used when you must have access to something that the normal user doesn't. Some distributions (like Ubuntu) even enforce this by not allowing root logins and forcing the user to use sudo for commands that require root access.
Bottom line is this: It's your server, so use root if you want. Just be aware of the dangers and don't try to blame anyone other than yourself when a typo or misbehaving build script takes down the system.
On 2/4/2014 9:15 AM, Bowie Bailey wrote:
On 1/1/2014 6:53 PM, Eliezer Croitoru wrote:
I want to make sure that while compiling as root nothing will break down inside the machine.
The basic issue is limiting your exposure in the case of a problem.
this is a month old thread, that was hammered into the ground, with the OP arguing with each answer he was given.
On 2/4/2014 2:57 PM, John R Pierce wrote:
On 2/4/2014 9:15 AM, Bowie Bailey wrote:
On 1/1/2014 6:53 PM, Eliezer Croitoru wrote:
I want to make sure that while compiling as root nothing will break down inside the machine.
The basic issue is limiting your exposure in the case of a problem.
this is a month old thread, that was hammered into the ground, with the OP arguing with each answer he was given.
I am a bit behind on this list. I read through the thread, but didn't notice the dates.
-
Bowie Bailey -
Eliezer Croitoru -
Frank Cox -
John R Pierce -
Johnny Hughes -
Markus Falb -
Stephen Harris