I guess I will keep using sbopkg as root and any other local slackbuild I will run with fakeroot

From http://slackbuilds.org/faq/#root

That's is what I am currently doing.

I wouldn't go as far as to say "Don't ever build as root", but I would say that if you do, understand the risks and be prepared.


I agree with Rauri, fakeroot is a useful tool, but it's not a magic bullet. I took a different approach with some of my build scripts. My scripts are designed to run as non-root and do the unpack/configure/make/make install as a non-root user (sometimes the 'install' section of the makefile needs to be patched to take out any chown/chmods that it does - fakeroot would be another way of addressing this, but I tend to patch it out instead.) Then, at the end of the build script I call a wrapper around makepkg as root via sudo. Setting any special permissions that may be necessary is deferred until the package is installed by including specific chown/chmod in the doinst.sh script instead.

It can sometimes take a little extra effort to write the build scripts this way, but the majority of packages don't need any special permissions. It's not the standard slackware or SBO approach but it works for me, and avoids a lot of the dangers of building software with root.

I find the slackbuilds.org view on that somewhat missing the point. I trust slackbuilds.org scripts (Well, I still give them a once over before running them, but I expect not to find any maliciousness when I do). However, do the slackbuild.org guys check every line of that massive ./configure script monstrosity or the makefile from the upstream sources for any maliciousness? I'm guessing not, and neither do I as it would be far too much effort, but I'm not going to be running it as root either, if I can help it!

And it's not just maliciousness, genuine mistakes can be just as deadly.


It's not really that I don't want to run the build script as root that is the issue, its that I don't want to run the configure/make/make install as root.

1 members found this post helpful.

I also have my own makepkg which alters the behaviour of -c, --chown such that when it is set to y it also changes file ownership to root:root. This allows me to have SlackBuilds that create root owned files packages as a regular user, without even using fakeroot.

1 members found this post helpful.

This is certainly a fair point. Maybe I'll alter my behaviour after all. So far I have not had an issue (that I am aware of) but perhaps it is better to live cautious.

And then there's this, from http://slackbuilds.org/howto/
I've always run SlackBuilds as root, using su -, no problems so far (touch wood, fingers crossed).

I am sorry, but Slackware does not support the building of packages as non-root.
You do your homework first (as non-root user) to find out how the software configuration, compilation and installation works and to catch potential pitfalls, then you write a SlackBuild script and execute that as root.

Fakeroot and ruario's makepkg variant are helpful and perfectly acceptable, but your statement "never run a build script as root" is not the correct advice for Slackware. It is your opinion and you should probably mark it as such.

Eric

2 members found this post helpful.

Yes - maybe I quoted this a little bit out of context.

But I resent this being perpetrated as my opinion.

This statement has been a best practice for Unix Sys Admins for 20+ years.

And this best practice is what I was taught 20+ years ago by people who were smarter than me.

Please read the install file from gnu autoconf for example:
If you want to put aside something that has been a best practice for 20+ years, that's of course your prerogative.

But please do not make it sound like this is my personal opinion.

PS: I purposely refrain from bolding certain words, even though I think they should be.

Things change over time. 20+ years ago we wanted less transistors and more R/C/Ls in circuits to reduce cost, now we want less R/C/Ls and more transistors for the same purpose.

Nowadays a careful organization should have separate build machines. You may also use Linux control groups to put root into a container.

We're talking about two different things here. The need to run SlackBuilds as root, and the configure, make, make install, procedure where only make install should be done as root. That was obvious to me, did nobody else notice?

I apologize if my response sounded too harsh.
Let me try to phrase it better.

There is a difference between using a build script (a SlackBuild in Slackware, a SPEC file in Redhat, a PKGBUILD script in Arch etc...) and compiling a piece of software by hand.
When you are manually compiling software and installing it into the system directories (even /usr/local) it does make sense to compile using your own user account and use root only for the final "make install" step. But even then, a "make install" can break your system no matter how careful you were with the compilation process.

A build script for the distro should be seen as the tested-and-tried recipe for the system administrator, which enables him to compile and install a piece of software in a controlled fashion. A build script which has been QA-ed should be run as root without ill effect. If software compiles differently when compiled as root, compared with a non-root user, then the writer of the build script must compensate for that.
It is a matter of trust levels. If you trust the person who created the build script, then you can run it as root. The Slackware community has a "web of trust" where there are some well-known sources of trusted SlackBuild scripts. I personally do not use any script which does not originate from one of the trusted sources.

Eric

3 members found this post helpful.

I disagree. We're talking about one thing: following the principle of least privilege in order to reduce the risk of accidental or malicious damage to the system on which the build script is running. In this case, it was a sloppily written slackbuild script that didn't "fail safe" that has prompted this discussion, but an error in the autotools scripts or makefile(s) can do just as much damage. Hell, even the 'tar -x' could be a problem if the tarball was created with '--absolute-names'.

The irony is that it's often the 'make install' that does the damage (most commonly, when the makefile author has missed a DESTDIR reference somewhere) and that's the bit that usually needs the most privilege.

Ideally the only thing you'd want to require running as root is the installpkg command. In the scheme I'm currently following, I still need root for the 'makepkg' (which is run via sudo), but if I stopped using makepkg and started to use tar directly (with '--owner=root' and '--group=root') then I could even remove the need for that, but I prefer to stick with using the official packaging tool for obvious reasons, despite its need for root.

Edit: oops wrong thread