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 )

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.