19 thoughts on - I Want To Ask About Some Kernel Level Operations.

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

  —
  MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ http://www.melvilletheatre.com

• 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!

  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

• 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

• Looking for a recommendation for one.. Please also add the price for learning from him.

  Thanks, Eliezer

• Eliezer wrote:

  > What would be a clean buildroot for?

  Well, only God himself did the initial creative work just once — after that, He let things go, because it was already to complicated even for Him — or perfect. Anyway, because He had not planned doing it again and reiterate, we now have theology and the subject of theodicy.

  And remember: even the pope uses ‘sudo’ when he speaks ‘ex cathedra’.

  So wtf are you asking for??

  -Michael

• Hey Michael,

  I have couple things but the main issue is that couple nice guys said something about CentOS. What I am trying is to learn from the bests!! and all the time. I see them at work I see them here and I see them on TV. I also tried to meet some of them but god have prevented me from meeting them by “default”. I will not complain on it..

  I have tried my bests at building some RPMs and by reading couple books about RPM and other levels.

  One of the greatest things I have seen until now is:
  http://vimeo.com/70019064

  Which can describe the needed muscles and brains to build a RPM.

  Thanks, Eliezer

• Actually I would go even further and not recommend to have a compiler installed on a server.

  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,

  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

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

  Please remember that my example was not about removing /dev/*
  but about removing /* , so why just not building as root?

  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?

• Well I am building as root when I understand it is safe to do so.

  OK.

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

  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

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

• Hey,

  I am still not sure if it’s Harald or Reindl as first name.

  Now for the matter in hands:
  I am building the software mostly manually if I can!
  The problem is that most software developers tend to build their software in a very good way. The kernel developers for example of a remarkable software is a very strict environment. If I cannot build the kernel as root user it is better to not build it at all from my aspect.

  The RPMBUILD tools and other automation tools is suppose to help distributing and test the code.

• you are replying to a private message that wasn’t posted to this list.

  I might also add, you seem determined to ignore all advice given, so why did you ask for it in the first place?

• We are talking mock the software for building rpms in a chroot, aren’t we?
  http://fedoraproject.org/wiki/Projects/Mock

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

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