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