WARNING - SlackBuilds and the like can break your system
 

My intent is not to be critical of the people who make the effort to supply most of us with easy to use build and installation scripts. I am grateful to them since I would have a much more difficult time getting software installed without their selfless efforts. This is just a warning to those who may not be aware of some of the possible problems that can occur when you run someone else's script.

I was building a truecrypt package using a SlackBuild. I discovered that my umask setting at the time I run the SlackBuild makes a big difference in the results I get. It seems like it makes a potentially system-breaking profound difference when you install the resulting package, depending on what your umask is set to.

Maybe most people know about this, but I didn't, so I wanted to warn the clueless like me.

I normally have my umask set to 0027 so that no world permissions are granted on any file or directory I create. With my umask set to 0027, I used lftp to mirror a SlackBuild package from Alien Bob's wonderful site.

Then when I executed the truecrypt.SlackBuild script it built the package in /tmp. The files in the package had permissions of 0640 (mostly) and the directories had 0750 because of my normal umask of 0027. I wasn't aware of this at the time.

Then when I installed the package, all the directories that the new files went into had their permissions changed to 750, including such critical directories as /lib and /usr and a few others. As soon as these directories were changed, my non-root users couldn't function anymore. I couldn't unlock them from KDE locked state. I couldn't issue many commands or run many programs under KDE (e.g., firefox). I couldn't logon at all except as root. I had no idea what caused the problem at the time, except that I knew I had just installed the package that the SlackBuild built for me. And to make matters worse, uninstalling it didn't fix anything. My woes are described in this thread Cannot execute /bin/bash: Permission denied.

After figuring out what happened and cleaning up the mess so my non-root users could logon again, I deleted all the truecrypt files and slackbuild and started over with my umask set to 0022. Now the resulting package got built with normal permissions; 755 for directories and 644 for files (mostly - there are some that get set differently like the .ko module and the compiled binary executables).

The version of the package that was built when my umask was 0027 broke my system when I used installpkg to install it. The version built when my umask was 0022 was fine.

Now I guess some people will say "of course, any dummy knows that". Well, not this dummy. I haven't been able to find any documentation or caveats from anyone who builds slackbuild scripts stating that your umask should be 0022 in most cases when running the script. I guess a script could set the umask to safeguard against this, but this one obviously didn't and many probably don't.

So - let this be a warning to anyone who uses SlackBuilds or, really, any installation scripts of any sort at all. Set your umask to something safe before you start building and installing. Unless you take the time to review everything carefully (which I think most people do NOT do), you never really know what those scripts are doing.

For me, a lesson learned. C'est la vie!

If you don't want to use the slackbuild ... you can just build it from source by yourself ... it's not hard (with the exception of a few programs). But, for more difficult programs to compile, just open up the Slackbuild script and see how it was going to be compiled, but run the relevant commands yourself ... or edit the script yourself.

Or, use the Slackbuild, then extract the resulting package (explodepkg), change the permissions as you wish, then re-package it (makepkg).

Most source packages seem to be designed for ./configure, make, make install, and that's what I normally do, except that I typically use checkinstall instead of make install. The truecrypt source package wasn't created with ./configure, make, make install, so that's why I decided to try the SlackBuild.

I'll try explodepkg and makepkg. Thanks for the tip.

Well maybe you're right and SlackBuild scripts should set umask=0022.
On the other hand, my own and SlackBuilds.org's SlackBuild scripts require you to be root when building the packages.

Now, the root user is someone who should not mask out the world-readable bits by setting a umask of 0027. After all, when root installs stuff, the installed files and directories should be accessible to every user on the system. A umask of 0022 makes sense for root. For ordinary users who want to make everything they create inaccessible to others, a umask of 0027 makes sense.

So in the end, the SlackBuild was not at fault (gotta defend my own ;-) but I will consider building in a check for the umask in future versions of my SlackBuilds.
Thanks for bringing this to my attention.

Eric

Eric, I agree. Your SlackBuild was not at fault. After reading your response, I understand even better now than I did before how umask and other settings and the intended roles of different accounts on a Linux system relate.

In the interest of improving overall system security (I thought), I had changed /etc/profile to set a umask of 027 for all users at login. That's how I want my normal user accounts to be set up by default, but I now understand that this is not good for root. root is not a normal user and is accountable for the whole system. It is therefore necessary for the root administrator to truly understand what he is doing and how his actions affect the system.

Was I told this before? Well, yes, as a matter of fact, there are countless warnings from many quarters about the unlimited power and responsibility of the root user and his ability to affect system stability. The difference for me is that I now have an empirical understanding of this rather than a merely conceptual one. A good lesson learned, and thankfully without irreparable harm.

I now have a .profile and a .bashrc in root's home directory to set the umask to 022.

I would advise you to run my pkgcheck and instcheck tools (see my sig) against any package you download or build. In this precise case, instcheck would have warned you that you'd change the permissions of existing directories.

Personally, I don't install any packages (from sources outside the Slackware distribution) without checking them first. Especially packages I've created myself.

The quickest way of doing this is to fire up Midnight Commander (mc), highlight the package and press F3. This will enable you to "browse" through the package and see which files will be placed where. More importantly, it shows the ownership and permissions on each file and directory within the package.

@Z038

thanks, I for one did not know or think about this stuff before your thread. Gives me something to think about and hopefully will prevent a problem in the future.

Sorry you had to have the problem, but thanks for sharing with us all as I for one have learned something new.

(and thanks also to those with actually constructive suggestions too :D )

Hi AlienBob,

I noticed for this specific Slackbuild you have a patch but I didn't have time to figure out whether it was already built into your Slackbuild or whether we need to patch the source before running your script. For this latest truecrypt version can we just download source and run your script or what's the deal?

Thanks
Rand

As with all my scripts, all you do is download the content of my 'build' directory, `cd` to that directory and run the SlackBuild script there. It will download the source if it is missing and produce the ready package in the /tmp directory.
Like this:
The latest truecrypt release requires less patching than before - I used to need patching in order to let the SlackBuild script create packages for arbitrary kernel versions.
All I patch for now, is to show the shitload of warnings that the compilation produces and that the developers are anxious to hide from the general public ;-)

Eric

Actually, even for a small, simple, and correct C programs, gcc will through many warnings at you, and a lot of them just don't make sense.

"use of -Wall in this context is deprecated, please turn off monitor while compiling."

Thanks Eric/AlienBob. :)

Keep up the brilliant work!

Cheers,
Rand

I'm arriving late to this one, but I thought I'd throw this in...
While I understand the potential issue here, I want to reiterate that the problem was *NOT* caused by the SlackBuild script at all - this was the result of a user changing a default system setting without understanding the ramifications of doing so. In that respect, it wouldn't have mattered if the user had built the package manually, with a SlackBuild script, or even using plain old "configure --prefix=/usr && make && make install" - unless, the Makefile for that particular app covered for this sort of thing by specifying a mode for the installed directories and files, it would have still caused the problem that occurred.
I realize that the OP has since more or less retracted the original warning, but for future reference, please consider asking about a potential problem before posting a dire "WARNING" to spread FUD among users.

As an afterthought, Erik Jan Tromp (alphageek) pointed out another obvious (in hindsight) idea - it's a *really* good practice to build packages in a *clean* development environment. In other words, set up a chroot environment on your system and build all add-on packages in there.
Setting up a chroot is pretty easy to do:
1. Make sure you have adequate space (on modern systems, that should not be an issue).
2. Select a directory; I like /chroot on a separate partition, but that's your call. If you have a separate (large) drive mounted somewhere else, such as /shared, maybe /shared/chroot is a better option.
3. Create the directory - mkdir -p /chroot
4. Use the ROOT environment variable to install a complete Slackware installation to the chroot directory.
ROOT=/chroot installpkg /path_to/slackware_packages/*/*.tgz
5. chroot into your new environment with "chroot /chroot /bin/bash -l" and maybe set up a few things as needed. I like to set my timezone and network (at least /etc/resolv.conf) so that I can use the net while in the chroot if needed. You can use pkgtool to do this or do it manually.

I'll leave it as an exercise for the reader as to how to keep the development environment updated with patches and such. Theoretically, it's not a big deal, but on occasion. things are added to /patches that might make a difference in compiling packages later.

Wouldn't 'fakeroot' save a lot of time and space, rather than installing a whole nother Slackware ... ?

No; you missed the point of the clean development environment. Hint: it hinges on *clean* - it ensures a pristine system on which to build, so that the OP's problem doesn't occur, and if you happen to decide to redistribute the resulting packages, you can be reasonably assured that they don't have any unplanned dependencies.

In fact, fakeroot wouldn't have prevented the OP's problem at all.

i think it's to prevent dependencies to get build in (e.g. if ./configure detects s.th. from another non-slackware package)

I do not retract my warning and there is nothing about my post that constitutes the spreading of FUD. The warning is relevant and the risk is real, particularly for those who either do not pay attention or who lack the experience to understand what they are doing. The latter was my particular failing, but the incident was valuable to me nonetheless because of what I learned in the process. And fortunately I'm not so dumb that I couldn't figure out how to extricate myself from the mess I made.

What I clarified in my third post in this thread was that it was my lack of understanding, and not the script, that was responsible for the problem. That is not to say that I think scripts like these could not be improved to make them safer for the inexperienced user. I think they can be, and building in additional checking and safeguards would be beneficial for the people who are the most likely to use them.

You suggest that I consider asking about a potential problem before posting a warning. I did so in this thread Cannot execute /bin/bash: Permission denied. I got some good pointers from responders there who helped me understand what was wrong, but ultimately I figured out on my own why it was wrong and how it happened. I started this thread because of my newly acquired knowledge, and inasmuch as it has been viewed more than three times as often as the original thread (currently 775 views compared to 239), I conclude that I accomplished my objective, which was to alert others to the possibility of such an occurrence.

Yes, so why the refusal to retract?

Where does that end? Does Pat need to provide a default alias to make rm(1) ask for confirmation before deleting files? How far should we (SlackBuild creators) or Pat or anyone else go to protect users from their own mistakes?

Yet you still started this thread with a dire WARNING about SlackBuilds, but it should have been a warning about users setting a bad umask setting for the root account.

Of course it has. I can only hope that the viewers don't stop reading after the first post.

I find the SlackBuilds site to be well-documented, organized. I very much appreciate the time and effort it has taken to create the build scripts for the wide variety of applications listed.
As a Slacker it is wonderful to have the choice of compiling from source, using SlackBuild scripts, or installing Patrick's packages.
I have not encountered any serious problems using SlackBuild scripts.
Many thanks to Robby, Eric and the SlackBuild team for your support:-)

I built a live cd that I use for compiling software and testing build scripts on, so I must admit if you can have a clean environment to work with, it certain wouldn't hurt.

What do you believe warrants retraction? Take care to ensure you understand what is written before you reply, else you may just be demonstrating your lack of reading comprehension.

The creation of slackbuilds is not demanded by some imagined compulsory software welfare system. Such a thing does not exist. Builders and users all have freedom of choice. Since no one is compelled to do anything they do not wish to do, I'd say it is your choice how far to take it. Make no usability or safety enhancements to your scripts if it suits you.

You are confusing immediate and root cause. The fact is that the root cause (bad umask) is only applicable because the slackbuild creates the package for install in that environment. Packages pre-built in a normal environment have far less potential to cause this particular effect. In fact, I've downloaded countless packages from the Slackware Packages site and then installed them as root with umask 027 and have encountered no ill-effects whatsoever.

Like a good book, who could put it down after reading just the first paragraph? This thread has all the elements needed to captivate the reader; it has danger, mystery, drama, and the classic thematic elements of man against nature and man against man. We have the antagonist (you) and the protagonist (me), duking it out in the dangerous realm of slackbuilds and unconventional umasks, while the innocent bystanders get caught in the melee.

Pull the stick out of your craw, understand that my original post wasn't intended to criticize you, and perhaps you'll feel better. I feel fine, by the way.

@ Z038:

In the interest of maintaining cordial relationships in the Slackware user community, this will be my last reply in this thread (as it pertains to this portion, anyway).

There may very well be a lack of reading comprehension; however, I think the attribution is misplaced.

Your reference to packages made elsewhere is a red herring, as it bears no relationship to this at all - of course a package created elsewhere (on a system with a *correct* umask for root) won't cause the problem you experienced.

There is no "stick in [my] craw" at all - while I could certainly be accused of at least a small amount of bias (pertinent to SlackBuilds.org), the facts remain like this:
1. You changed root's umask to a faulty configuration.
2. You ran a script that exposed your error.

For all you "innocent bystanders," I apologize for the harshness of my post, but I happen to have a serious problem with someone creating the impression (whether intentionally or not) that a SlackBuild script is responsible for the problem that occurred on Z038's system.

My warning is about the installation of slackbuilds. Contrasting this with an alternative that does not present the problem enhances understanding of the problem; it does not draw attention away from it.

1. umask 027 is not faulty. It is valid and is useful and desirable for some purposes. It is not useful or desirable for running slackbuilds that make assumptions about the umask. Hence my warning.
2. See response to 1 above. Using a umask of 027 is not an error. Running a slackbuild script that makes assumptions about the umask in such an environment is, and I've unambiguously admitted to that.

The funny (as in odd, not as in humorous) thing is that you have a problem with any of my comments at all. It wasn't one of your slackbuilds I used. I never heard of you before you started posting in this thread. I am not criticizing your site, your self, the product of your labor, your commitment to the Slackware user community, or anything else of or about you.

I believe the impression you claim is fostered by my original post exists only in your own mind. I have a suggestion for you. Dump your defensive posture and your mental biases and go read it again. Then answer these questions:

1) Who is my warning directed to? (see first paragraph and penultimate)
2) What do I identify as the root cause of the problem? (what was it I changed to make it work right?)
3) Where do I urge people not to use slackbuilds as a solution to the problem? (you won't find it)
4) Where do I criticize the authors of slackbuild scripts? (you won't find it)

Rather than attack me for imagined affronts, why not thank me for pointing out a way that you can enhance (notice I did not say "fix") slackbuild scripts to make them even more safe and useful than they already are. And keep in mind that I didn't direct this thread to you. You are the one who decided to make it personal.

Okay, so I lied - I *am* going to respond again :/

For a normal user account, I agree with you completely - there is absolutely nothing wrong with a umask of 0027. For root, well, that's an entirely different breed of cat...

I never got that impression, but thanks.

Do the same and read your subject line again; put yourself in my shoes when you do, and perhaps it will be a bit clearer.

On that note, I guess I should apologize - I never intended for this to become (and indeed didn't realize that it had become) personal.

To be honest, the actual *body* of your original post was fine - it's was (and still is) the subject line with which I have a problem. I put in the "whether intentional or not" above because I really didn't (and still don't) think that your intention was to create the impression that SlackBuild scripts (whether from Eric's site, my site, or wherever else you might find them) are problematic; *however* I *do* think that the subject line nonetheless creates that impression in the minds of readers. That was (and is) my primary disagreement about this whole thread. With a different subject line, my only contribution to this thread would likely have been the post about building in a clean environment...

Thanks; we appreciate the feedback from the user community. :-)

You are very welcome, Robby! Keep up the great work.:D

I've been staying out of it but why not. :D

I agree. It's a bad subject heading. It wasn't the Slackbuild that caused the problem. It was the Administrator overriding a default setting that broke the system. While we have already established this, the subject is still very misleading and could have been worded better. The only way a slackbuild could break someones system is if it's not written properly and does a rm -rf $PK/etc or something silly like that. The heading instantly raises a red flag about Slackbuild scripts before someone has even had a chance to read it. Ofcourse, once I read the OP, it was made clear what happened. No biggie. Just a bad subject heading... ;)